[concurrency-interest] Enforcing total sync order on modern hardware

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Mar 17 12:42:38 EDT 2015


On 03/17/2015 06:57 PM, Marko Topolnik wrote:
> On Tue, Mar 17, 2015 at 3:56 PM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> I am trying to work my way starting from specified guarantees, taking
> care not to introduce tacit assumptions such as the transitivity of
> separately guaranteed total orders. But yes, at some point empirical
> evidence takes over the documented guarantees.

If you are looking for documented guarantees that include hardware
memory consistency, the full JMM consistency rules, and explain any
phenomena you throw at it, then you are in for a
<strike>surprise</strike> long haul!



>> These intricate details on hardware concurrency is one of the reasons we
>> have JMM. JMM explicitly requires the total order on synchronization
>> actions, and JVM implementors are responsible to figure out how to map
>> it back on hardware, let it be fences or locked instructions or what.
> 
> Sure, that's exactly what I was asking about: how does JMM efficiently
> translate into hardware given the ever more distributed nature of the HW
> architecture.

So, big picture view: hardware does provide the totally ordered
(sequentially consistent) operations. locked insns and/or fences on x86;
hwsyncs/etc on POWER; dmb/ll/sc on ARM, etc. JMM implementations, as
well as C/C++11 implementations almost directly map their total ordered
sync ops to those hardware primitives.

It is a hardware problem how to maintain total ordering. The simple
mental model that fits simplified message-passing coherency protocol is
relatively easy to construct. It deliberately does not talk about
intricate topologies, and other bells and whistles, because the original
question was about maintaining the total order in the absence of a
globally lockable shared bus.

Thanks,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150317/3e56bcef/attachment.bin>


More information about the Concurrency-interest mailing list