Re: Volatile semantic for failed/noop atomic operations

2019-10-08 Thread Vitaly Davidovich
On Sat, Oct 5, 2019 at 11:41 AM Steven Stewart-Gallus < stevenselectronicm...@gmail.com> wrote: > Couldn't you do a compare and compare and swap? With VarHandles something > like > > if (ACTION.getOpaque(this) != expected) return false; > return compareAndExchange(this, expected, newValue) ==

Re: Volatile semantic for failed/noop atomic operations

2019-10-05 Thread Gil Tene
That's actually the common idiom for performant concurrent code that occasionally needs to do something atomic, but usually (the hot case) doesn't. Without the first read check, there is a good likelihood (depending on how the CPU and prefetchers work for CAS, but very probably) that you will

Re: Volatile semantic for failed/noop atomic operations

2019-10-05 Thread Steven Stewart-Gallus
Couldn't you do a compare and compare and swap? With VarHandles something like if (ACTION.getOpaque(this) != expected) return false; return compareAndExchange(this, expected, newValue) == expected; Not sure I got this correct On Saturday, September 14, 2019 at 11:29:00 AM UTC-7, Vitaly

Re: Volatile semantic for failed/noop atomic operations

2019-09-25 Thread Francesco Nigro
> I've never heard of failed CAS being cheaper I'm referring to this old (but good) article: https://blogs.oracle.com/dave/biased-locking-in-hotspot Il giorno sabato 14 settembre 2019 21:41:56 UTC+2, Vitaly Davidovich ha scritto: > > On x86, I’ve never heard of failed CAS being cheaper. In

Re: Volatile semantic for failed/noop atomic operations

2019-09-15 Thread Simone Bordet
Hi, On Sun, Sep 15, 2019 at 2:24 AM Vitaly Davidovich wrote: > In your snippet, terminate() sets the field - it can be visible immediately > (or terminate() thread is descheduled). decrement runs, decrements to 0, > sees action != null. terminate() also now sees 0, and likewise proceeds to

Re: Volatile semantic for failed/noop atomic operations

2019-09-14 Thread Simone Bordet
Hi, On Sat, Sep 14, 2019 at 8:28 PM Vitaly Davidovich wrote: > > Unlike C++, where you can specify mem ordering for failure and success > separately, Java doesn’t allow that. But, the mem ordering is the same for > failure/success there. Unfortunately it doesn’t look like the javadocs >

Re: Volatile semantic for failed/noop atomic operations

2019-09-14 Thread Vitaly Davidovich
On x86, I’ve never heard of failed CAS being cheaper. In theory, cache snooping can inform the core whether it’s xchg would succeed without going through the RFO dance. But, to perform the actual xchg it would need ownership regardless (if not already owned/exclusive). Sharing ordinary mutable

Re: Volatile semantic for failed/noop atomic operations

2019-09-14 Thread Francesco Nigro
Although not mentioned (neither on Doug's cookbook) I have always supposed was more likely the c++ default for both weak/strong CAS ie seq_cst memory ordering. To make this question more mechanical sympathy focused: on hardware level what happen? I would be curious to know both x86/arm versions