Mpsc ringbuffer Agrona

[Francesco Nigro]

Hi guys!!!

Any of you have understood the meaning of Unsafe.storeFence() inside the ManyToOneRingBuffer in Agrona?
Why a volatile store (StoreStore & LoadStore) on the header instead of a putOrdered (StoreStore) on the header + storefence() (StoreStore & LoadStore) couldn't have the same effect?
If I get properly the "doc" such a fence has a release meaning...

Thanks!!!

[Martin Thompson]

The use of storeFence() in this code is to ensure the write of the bytes to the message body does not migrate ahead of the first write to the header with the length field which is a required order for the protocol.

The required semantics is an atomic write followed by a StoreStore which is not provided by putOrdered. The putOrdered is effectively a StoreStore followed by an atomic write.

A volatile write on the header would have the required semantics, and some, but involves a hardware fence. The approach taken in Agrona is more efficient for this case.

--
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-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francesco Nigro]

Thanks Martin, 

i'm trying to get it right looking at the OpenJDK's source code.

I've found a brief summary here: https://bugs.openjdk.java.net/secure/attachment/23833/VolatilesAndTheMemoryModel.htm

A volatile store implies a "membar", hence it's translated (at least) as an hardware (>=) StoreLoad for all the archs while (it's not specified in the provided link, but it's seekable on the source code of the last version of the OpenJDK) Unsafe:storeFence() is intrinsified issuing the membars Op_MemBarCPUOrder e Op_MemBarVolatile:

bool LibraryCallKit::inline_unsafe_fence(vmIntrinsics::ID id) {

  // Regardless of form, don't allow previous ld/st to move down,

  // then issue acquire, release, or volatile mem_bar.

  insert_mem_bar(Op_MemBarCPUOrder);

  switch(id) {

    case vmIntrinsics::_loadFence:

      insert_mem_bar(Op_MemBarAcquire);

      return true;

    case vmIntrinsics::_storeFence:

      insert_mem_bar(Op_MemBarRelease);

      return true;

    case vmIntrinsics::_fullFence:

      insert_mem_bar(Op_MemBarVolatile);

      return true;

    default:

      fatal_unexpected_iid(id);

      return false;

  }

}

I'm hoping to have found the right place to look at...or there are other "places" that explicit better this constraints?

Anyway, i've catched the optimisation and yes, without finer grain control on barriers issued seems the best choice here.

I'm curious to know the impact of that unavoidable LoadStore: from an hardware pow (at least) on x86 is clear it doesn't exists but from a compiler pow it's a completly different story and could prevent other optimisations... 

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Martin Thompson]

This is the same list I use for reference. Note the very last line for the put ordered semantics.

"However, both the native implementations in unsafe.cpp and the C1 intrinsic versions, implement these identically to the volatile versions, with no relaxing of the memory barriers. Only the C2 intrinsics actually elide the trailing barrier."

Without that barrier you need a StoreStore fence to keep the store order. On platforms other than x86 the storeFence() could become more costly and be similar to the volatile write.

Thanks Martin, 

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-symp...@googlegroups.com.

[Francesco Nigro]

I understand...anyway without that link,moving on openjdk'sources is not that simple (for me at least!) considering instrinsic/c1/c2/native etc etc.

Needs to find out with JHM on ARM (i've a lot of Raspberry PI at home :P) if a volatile write have the same cost of a ordered one? The trailing fence (if present) could have a performance impact per se? With a microbench that only write something?mmmm...

[Francesco Nigro]

Old but good: http://gvsmirnov.ru/blog/tech/2014/02/10/jmm-under-the-hood.html

Traces the points on OpenJDK's source code to find the incriminated additional StoreLoad barrier emitted at the end of the volatile stores...

[Nitsan Wakart]

see recent clarification from Shipilev on concurrency-interest:

http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/15178

--

[Francesco Nigro]

Thank you Nitsan,

it's a very valuable link!!!

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.