[concurrency-interest] Unsynchronized lazy conditions

Aleksey Shipilev shade at redhat.com
Thu May 31 06:15:12 EDT 2018


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180531/31a7bc33/attachment.sig>


More information about the Concurrency-interest mailing list