[concurrency-interest] Unsynchronized lazy conditions

Viktor Klang viktor.klang at gmail.com
Thu May 31 06:16:48 EDT 2018


+1

On Thu, May 31, 2018 at 12:15 PM, Aleksey Shipilev <shade at redhat.com> wrote:

> I think Viktor wants to avoid volatile read on the fast path. Assuming
> that even matters, we can do
> this with VarHandle doing the plain fastpath read, and then CAS to get
> exactly-once semantics.
> Since, as you say, that thing would be executed approximately once, there
> is no loss in doing the
> right thing, while we are at it.
>
> E.g. (sketching):
>
> class Foo {
>   static final VH = <varhandle-over-x>
>   boolean x;
>
>   public void run() {
>     if (!VH.get(this) // non-volatile fast-path
>            && VH.compareAndSet(this, false, true)) {
>       LOG.warn(...);
>     }
>   }
> }
>
> But I tend to think this is an overkill, and the plain field is good
> enough already. Make it
> volatile if unsure.
>
> -Aleksey
>
> On 05/31/2018 12:05 PM, Alex Otenko wrote:
> > Who cares to optimize the instruction that is going to be executed
> approximately once?
> >
> > Alex
> >
> >> On 31 May 2018, at 11:03, Viktor Klang <viktor.klang at gmail.com <mailto:
> viktor.klang at gmail.com>> wrote:
> >>
> >> Or leave the field un-volatile and introduce a release fence before the
> logging call?
> >>
> >> On Thu, May 31, 2018 at 11:58 AM, Alex Otenko <
> oleksandr.otenko at gmail.com
> >> <mailto:oleksandr.otenko at gmail.com>> wrote:
> >>
> >>     The original requirement was it’s ok to sometimes log Warning
> several times. All this hacky
> >>     atomicity is unnecessary. Just declare private volatile boolean
> warned, and leave the rest of
> >>     the code as is.
>
>


-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180531/a0ffa65e/attachment.html>


More information about the Concurrency-interest mailing list