Phil Endecott wrote:
Anthony Williams wrote:
"Phil Endecott" <spam_from_boost_dev@chezphil.org> writes:
Anthony Williams wrote:
One principle behind the new lock templates is that it should be easy to incorporate new mutex and lock types, and they will still work with the existing facilities (e.g. condition_variable_any).
Hi Anthony,
Can you clarify what you mean by that please? Are you saying that if I have a new mutex (e.g. my futex implementation) I should be able to use it with the existing condition_variable_any? (Is that what the "_any" means?) If that's true I'm impressed; I thought that it was necessary to have some sort of atomic unlock-A-and-lock-B method to do that.
Yes, that's what I meant, and that's what the _any means (as opposed to condition_variable which only works with unique_lock<mutex> (also known as mutex::scoped_lock)).
No, you don't need an atomic unlock-A-and-lock-B method, but it does need an extra internal mutex.
Thanks! I've found your source (for the pthreads version) here:
http://svn.boost.org/svn/boost/trunk/boost/thread/pthread/condition_variable...
That condition_variable_any wrapper doesn't ensure same destruction safety of condition varaible as POSIX pthread_cond_t. That's not good. regards, alexander.