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) == expected;
>
> Not sure I got this correct
>
In general you could. This is sometimes referred to as TTAS (test and
test-and-set).
In this thread’s example, the “checks the count via a volatile load” I
mentioned is a similar effect; under some conditions, and opaque load might
be slightly cheaper than a volatile one (on x86 at least). The difference
would only really be a result of the optimizer doing other scheduling
around the opaque load, but not around a volatile one.
The right/best approach for Simone’s case depends on specifics (don’t they
all?! :)). I didn’t actually pick up on how often the termination protocol
triggers - I assumed it’s an uncommon/slow path.
>
>
> On Saturday, September 14, 2019 at 11:29:00 AM UTC-7, 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
>> mention that, but I recall Doug Lea saying that’s the case on the
>> concurrency-interest mailing list (btw that’s probably the more appropriate
>> channel for this Java-centric question).
>>
>> For your case, it seems like an AtomicReference<Runnable> is more
>> appropriate. terminate() sets it, then checks the count via a volatile
>> load (or maybe it can decrement() itself?); if zero, CAS null into the
>> action field to take/claim the action. decrement() likewise tries to claim
>> the action via a CAS. The snippet you have now would allow for concurrent
>> action execution, which is likely unsafe/wrong.
>>
>
>> On Fri, Sep 13, 2019 at 3:08 AM Simone Bordet <simone...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have an atomic counter that gets incremented and decremented over
>>> time (non monotonically).
>>> At a certain point, I would like to enter a termination protocol where
>>> increments are not possible anymore and I set an action to run if/when
>>> the counter reaches zero.
>>> Trivial when using synchronized/lock, but I'd like to give it a try
>>> without them.
>>>
>>> class A {
>>> private final AtomicLong counter;
>>> // Non-volatile
>>> private Runnable action;
>>>
>>> void terminate(Runnable action) {
>>> this.action = action;
>>> // Volatile write needed here for visibility.
>>> if (counter.addAndGet(0) == 0) {
>>> action.run();
>>> }
>>> }
>>>
>>> void decrement() {
>>> // Volatile read required to see this.action.
>>> if (counter.decrementAndGet() == 0) {
>>> Runnable a = this.action;
>>> if (a != null) {
>>> a.run()
>>> }
>>> }
>>> }
>>> }
>>>
>>> Is addAndGet(0) a volatile write? Can the write be optimized away?
>>> Similarly (although not relevant for this particular example), a
>>> _failed_ compareAndSet() has the semantic of a volatile write even if
>>> the set part was not done because the compare part failed?
>>>
>>> Thanks!
>>>
>>> --
>>> Simone Bordet
>>> ---
>>> Finally, no matter how good the architecture and design are,
>>> to deliver bug-free software with optimal performance and reliability,
>>> the implementation technique must be flawless. Victoria Livschitz
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mechanical-sympathy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mechanical-sympathy+unsubscr...@googlegroups.com.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ3qGJ_qqrXmAHNDZ6ro01BQwe8czHZP7b-SoZ%2BrULhJAw%40mail.gmail.com
>>> .
>>>
>> --
>> Sent from my phone
>>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/43729dfa-1e73-4318-b446-e80c81422b6e%40googlegroups.com
> <https://groups.google.com/d/msgid/mechanical-sympathy/43729dfa-1e73-4318-b446-e80c81422b6e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
Sent from my phone
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37Fjb01ReqeVtj26JxT%2BKhhsVVRpZx7J-CpDXi_ZDpF7ow%40mail.gmail.com.
