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? 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. Consequently a generally usable library would need to provide mutices for all three cases. I can see this as a policy that is fed to the ctor of the rwmutex in the original draft of Bill Kempf: writer_priority, reader_priority, alternating_many_reads, alternating_single_read I cannot see however a similar policy parameter in thread_rewrite version. How is this getting controlled in this case? Glancing over Anthonys code I can see that he is making use of some atomic primitives and semaphore calls. So I think this should be portable fairly easy. 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? I'd very much like to see this happen. Not only is the generic version valuable as a fallback, but also as a reference to measure performance and correctness against. I propose the following roadmap: 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.) 1) Decide if the current interface proposed by Bill Kempf still is appropriate. 2) Correct the bug that is present in Bill's current (generic) implementation. 3) Optimize for each platform. Please give me your feedback about these issues. Thank you Roland