On Aug 22, 2007, at 4:56 PM, Austin Bingham wrote:
On 2007-08-22, Howard Hinnant <howard.hinnant@gmail.com> wrote:
I have two answers:
1. This is somewhat of a shocking answer, so please read through the second answer before passing judgement: The proposal purposefully does not mention shared vs exclusive priority. And I would prefer not to.
2. The implementation uses an algorithm which I attribute to Alexander Terekhov.
At the risk of defiling a perfectly good metaphor, I think that if Alexander's algorithm is the car, then other policies are more like light trucks, pontoon boats, and tricycles. That is, the algorithm you describe almost certainly works as suggested, but I may really want something completely different. For instance, I may want to service readers as long as there are readers, potentially starving writers. Or vice versa...my point is that I think there is room for flexibility here. It's probably more of an academic point than anything, but it's a point nontheless :)
I'm not really pushing for the addition of shared_mutex policy configurability in what you've proposed. IMO it would likely be unneeded complexity. However, unless you're going to mandate the algorithm you describe, I think that an explicit statement that scheduling is undefined can't hurt.
I'll make sure such a statement gets into both the rationale, and (god willing) tr2, and thanks. Such a statement might include a note that std::tr2::shared_mutex has no exclusive right to the read/write mutex domain. I.e. I implemented shared_mutex non-intrusively on top of the existing threading lib, which means anyone else can write one too, with whatever policies desired, and have them work with the standard locks (if they follow the standard interface). Hopefully they will have access to an easy way to debug the use of the internal condition variables, and a zero-overhead std::condition for the final code. :-) (it sure helped me) -Howard