[cpp-threads] N2800's C/C++MM and read-write locking

[Alexander Terekhov]

On Mon, Jan 5, 2009 at 8:15 PM, Boehm, Hans <hans.boehm at hp.com> wrote:
> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html#write-fences
> for an old and partial rationale.
>
> Read locks are indeed a somewhat valid counter-argument.  But I have
> never seen empirical evidence that read-only ordering constraints
> would really speed that up on major architectures.  (I think it
> doesn't matter on X86, PowerPC, ARM, and Itanium.

X86 aside for a moment, think of "Safe Fetch" (Book II) on Power or
something less hacky, a more general, future Power's "sync" barrier
hypothetically called {ls}sync (load-store barrier) or some such...
after all, consider that {lw}sync ({hw}sync minus store-load barrier)
was added long after {hw}sync. Why couldn't you imagine akin
development for ARM and/or Itanium?

>
> I also often tend to think of "rwlocks" as shared/exclusive locks.  If you really
> want to use weaker fences for readers, I think you would need to split them
> into two variantes: shared/exclusive and read/write.

Care to elaborate? Do you mean write-only in addition to write-read
and read-only? I agree, why not?

>
> Based on what I've seen, the added complexity just isn't worth it.

Hardware aside for a moment, how about unnecessary restrictions
imposed on compilers regarding reordering?

regards,
alexander.