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

[Boehm, Hans]

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.  I'm not sure how much of a difference it makes on SPARC.  I doubt it matters on MIPS, though I don't really have access to a current spec.)

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.

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

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf
> Of Alexander Terekhov
> Sent: Monday, January 05, 2009 10:25 AM
> To: C++ threads standardisation
> Subject: [cpp-threads] N2800's C/C++MM and read-write locking
>
> Unless I've somehow missed it, N2800 doesn't offer any
> support for read-write locking in the sense of allowing
> different reordering constraints for read locking operations
> vs write locking operations...
> to begin with, think of rwlock.{rd}unlock() for holders of
> read locks and preceding stores, abusive use of rwlocks aside
> for a moment. Why is that? TIA.
>
> regards,
> alexander.
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>