|
Boost : |
From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-06-28 16:39:14
My question was more about the design rather than how I could work it
around. I may be wrong but specializing mutex does not look like a good
idea as it appears to be lock-specific functionality. So, I thought we
might consider having only mutex and typedefing others to it (not to
break old code) -- the simpler the better. Isn't it?
V.
> Do we need all three separate concepts -- mutex, try_mutex and
> timed_mutex?
I think the idea was that it would be possible to implement the mutex
types that supported fewer operations more efficiently. Whether this
actually turned out to be true is another question.
> I'd expect the mutex concept to remain unchanged and "try"
> and "timed" refinements to be related solely to the ways I try locking
> that only mutex. That is, I always have one mutex and under different
> circumstances lock it unconditionally (scoped_lock) or try locking it
> and check if that attempt succeeds (scoped_try_lock) or try locking
> within a certain time period (scoped_timed_lock).
If you want this, just use a timed_mutex and scoped_timed_lock. In the
current release it supports lock() and timed_lock() operations; in the
next release it will support try_lock() as well.
Mike
------------------------------
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
End of Boost Digest, Vol 772, Issue 2
*************************************
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk