Re: Are there real use cases with the Java access modes?

The example for fetch_add with memory order parameter is available in Rust
and C.

The different examples of code would be: counting watermark. Here the loads
and releases done by fetch-add I presume are not "normal", but opaque.

A case with release semantics is the common serialization routine: if
fetch-add with release ordering returns zero, you enter the critical
section; if non-zero, then you can assume your changes to shared data
structure will be observed by the contender that observed 0 for this
fetch-add. Then before exiting the critical section it suffices to do
fetch-add with acquire ordering. If this fetch-add results in non-zero,
some contender attempted to enter.

if (contenders.getAndIncrement() >0) return; // release ordering

for(int c=1; c>0; c=contenders.addAndGet(-c)) // acquire ordering
// process changes to shared data structure, and, say, write to socket


Of course, there are some assumptions about shared state modified outside
this loop, and shared state accessible inside the loop.

Alex

On Sun, 18 Jul 2021, 00:33 Shuyang Liu, <[email protected]> wrote:

> Thank you!
>
> > I know of a few like things achievable in other languages
>
> Is there an example of this?
>
> > Another important clarification needed is what barriers are enforced on
> failure of CAS
>
> Currently in our Herd implementation with Java, on a failed CAS, it
> treated equivalently as a read with its access mode specified. But I agree
> that it needs further confirmations on whether it is correct. So if it is
> `compareAndExchangeRelease`, then no barrier is enforced because the read
> in this case is a plain read. If it is `compareAndSet​`on a failure branch,
> then it is the same as a volatile read with a full barrier inserted either
> before or after depends on the compilation scheme. C11 does something
> slightly different (according to their Herd implementation). In addition to
> the read (with its specified memory order), it also performs a non-atomic
> write to `*expected` following that read if the compare fails. Since it is
> non-atomic, there is no extra barriers inserted for the write.
>
> I'll look for that email thread that you mentioned. It seems there might
> be something more to it.
>
> Best,
> Shuyang
>
> ------------------------------
> *From: *"Alex Otenko" <[email protected]>
> *To: *"Shuyang Liu" <[email protected]>
> *Cc: *"concurrency-interest" <[email protected]>
> *Sent: *Saturday, July 17, 2021 3:09:49 PM
> *Subject: *Re: [concurrency-interest] Are there real use cases with the
> Java access modes?
>
> I think one important case is an atomic increment that does not introduce
> full barriers (choose opaque, if you are just counting; acquire, if you are
> acquiring a semaphore; release, when releasing; or rel-acquire). I know of
> a few like things achievable in other languages, which probably are
> beneficial on many non-tso architectures.
>
> Another important clarification needed is what barriers are enforced on
> failure of CAS. I think there was a discussion about this on this list, but
> I don't recall if that resulted in a definitive answer about what it should
> be.
>
> Alex
>
> On Sat, 17 Jul 2021, 21:33 Shuyang Liu via Concurrency-interest, <
> [email protected]> wrote:
>
>> Hello,
>>
>> My colleagues and I have been working on a formal model for the Java
>> access modes that is added since Java 9 [1]. Are there any popular use
>> cases of access modes in real world applications/frameworks/libraries? We
>> would like to see how our current formal model works in real examples.
>>
>> Thanks you,
>> Shuyang Liu
>>
>> [1]. Using JDK 9 Memory Order Modes
>> http://gee.cs.oswego.edu/dl/html/j9mm.html
>> _______________________________________________
>> Concurrency-interest mailing list
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest