Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-22 17:32:18

On Aug 22, 2007, at 4:56 PM, Austin Bingham wrote:

> On 2007-08-22, Howard Hinnant <howard.hinnant_at_[hidden]> 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