[concurrency-interest] x86 NOOP memory barriers

Nitsan Wakart nitsanw at yahoo.com
Tue Aug 6 15:16:47 EDT 2013

> I  didn't have a chance to run this benchmark but one very significant point here is that the system is hyper threaded its only 6 'real' cores. My guess would be that volatile access generated lock instruction cause real stall for the other hyper thread.

Could be, but I'm not sure if this makes the experiment more or less realistic... I'm not sure how you tie this fact to the data. What do you expect the result to be with/without hyper-threading?

> Another factor is that test has read and write. The description says that atomiclongarray was used. .get method is volatile get and I guess it was used even for lazy version?

Get is a volatile read, for both the volatile and lazySet cases. I consider that appropriate as most people use either volatile directly or Atomic* to utilize lazySet, either way they will be paring the write with a volatile read. For what it is worth I have experimented in the past with replacing the volatile read with a plain read and it made no difference.

Thanks for the feedback :-) very much appreciated.

More information about the Concurrency-interest mailing list