Re: [boost] [thread] condition::notify with unlocked mutex

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-12-08 10:20:34

Roland Schwarz wrote:
> Yuval Ronen wrote:
>> I will gladly put my code here to be scrutinized by the experts on this 
>> forum (after the weekend, as the code is at work, and I'm at home now 
>> :-) ), but I fear that they will little incentive to do it.
> 
> Can't tell. Possibly yes. You will need to try.

I'll try.

>> Ok, I'm afraid I didn't explain myself properly. Apologies for that. 
>> What I mentioned only briefly, and had to emphasize more, is that the 
>> call to notify() will check to see if the mutex is locked - the mutex 
>> that was passed in the ctor, and throw an exception if not. The wait() 
>> function does it already, except that it should be changed to check the 
>> stored mutex&.
>>
>> I hope this explanation helps answering your questions above.
> 
> If it is only about protecting the user from as you say "bad usage", 
> where is the problem? If you need this behavior you easily can write a 
> little convenience-wrapper for your projects that achieves this goal.
> The threading library is designed to allow you the broadest valid usage, 
> only protecting from agreed misuses. Why should we unnecessarily limit 
> the libraries API when you can specialize it to your needs?

It's true I can write a wrapper to do what I want (I'll need to write a 
lock class which doesn't do any locking/unlocking, but only return true 
to an is_locked() question, which is not very pretty, but still 
feasible). The thing is that I thought I wasn't limiting any valid 
usages, and all users of the library can benefit from this change. We 
obviously disagree about that crucial point.

> And even if you might find out that there is a way on windows where your 
> proposed change allows for a faster implementation, you still would need 
> to prove that this also holds for other operating systems.

I intended to show that it's faster on Windows, and not any slower on 
other platforms. That should be enough, performance-wise. Peter showed 
that I'm avoiding some possible optimizations, which makes it slower on 
some platforms. As I said, should this optimization issue affect the 
interface might just be another issue we disagree about.

In face of all this disagreement, well, what can a guy do...