[concurrency-interest] Unsynchronized lazy conditions

Alex Otenko oleksandr.otenko at gmail.com
Thu May 31 06:19:49 EDT 2018


I don’t get this advice.

Do the simple thing, declare it volatile. Optimize further (learning curve + operational subtleties) when that is not fast enough. (VH.get cannot be different from volatile load on x86, can it?..)

Alex

> On 31 May 2018, at 11:15, 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.
> 



More information about the Concurrency-interest mailing list