Alexander Terekhov <terekhov@web.de> wrote:
Matt Hurd wrote: [...]
The "unidirectional label" model proposed by Alexander Terekhov is better.
Not sure what that is. I'll google it up.
http://tinyurl.com/aj9xa http://tinyurl.com/72ukl
regards, alexander.
Thanks Alexander. Your level of comprehension is way beyond mine. Especially after the dizziness of following your links :-) I think there is a place for your detailed approach, however I do think the majority of users are simple folk like myself and straightforward load/store/full fences will be the appropriate level of optimization at the step after needing more performance than regular locking. I'd imagine a taxonomy of sophistication something like... single threaded -> concurrency via frameworks and patterns -> using just mutexes and locks directly -> using barriers appropriately -> going down the rabbit hole into dd,cc,hoist,acq,rel land with Alex... ;-) That said, for naive users do you have an opinion on the memory semantics locking and unlocking a mutex should provide to deliver "the least surprise" to a user. x86 and sparc deliver a full fence for these AFAIK but I worry that memory visibility could cause seemingly safe mutex protected code to trip up on weaker memory models due to memory visibility surprises from point of view of those from the great unwashed x86 land (like me). I'm thinking that a PBD could provide full fence (or perhaps just a store fence is appropriate on releasing a lock to deliver least surprise) semantics by default that may be overridden by explicit policy by an aware user. Your thoughts on memory vis requirements for locking and unlocking mutexes for the least surprise? matt.