Boost logo

Boost :

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...

Boost list run by bdawes at, gregod at, cpdaniel at, john at