Roland Schwarz wrote:
Having tried to catch up with the last RW-lock discussion I am left wondering what is the conclusion of the discussion.
In thread_rewrite there is an implementation from Anthony. This however currently is only for windows so far, correct?
POSIX already has a rwlock; it's a mandatory part of the threading support (despite having its own feature test macro). A reimplementation could be necessary if the Boost version supports upgradable locks, though.
As I do understand the problem (please correct me if I am wrong) there is not a single reader-writer problem, but three:
1) reader-priority rw-access 2) writer-priority rw-access 3) starvation free rw-access
which of these three cases applies is in the application domain and not in the domain of the library implementation.
I can't imagine a use case for a reader-priority rwlock; it seems to me that an rwlock is simply not the correct synchronization primitive in such a case. Linux NPTL seems to supply one, though. So I may be wrong. I think that we now have a fairly good idea of how a rwlock is supposed to operate, and that our understanding coincides with the POSIX specification, under the assumption that the threads have equal priorities. In a nutshell, the rule is: 'rdlock' succeeds in obtaining a read lock if and only if no thread has obtained a write lock and there is no thread blocked in 'lock'. In my opinion, we only need to do one version, and do it right.
However, since rw-mutices can be made of a mutex and some condition variables, shouldn't we follow the old principle of getting it correct first and optimize later?
The problem in this case is that a rwlock is almost purely a performance optimization. It is generally not used for its semantics (although I can imagine a few use cases for them); a mutex is replaced with a rwlock in an attempt to increase reader performance, preferably without slowing down writers to a standstill. Viewed in this light, a read/write mutex that is slower than an ordinary mutex for the typical use cases is - IMO - not really worth having in the library.
0) Decide if we want the current (broken) version in 1.34. Please note that this is URGENT. (A previous poll about this interestingly did not get answered by anyone.)
We've never wanted a broken version of any component in any release. :-)