|
Boost Users : |
Subject: [Boost-users] interprocess_condition::wait(scoped_lock<interprocess_upgradable_lock> &) missing
From: John Ky (newhoggy_at_[hidden])
Date: 2011-02-02 20:16:10
Hi boost users,
I've discovered that the following doesn't compile.
using namespace boost::interprocess;
interprocess_upgradable_mutex mutex;
interprocess_condition cv;
boost::posix_time::ptime deadline;
{
scoped_lock<interprocess_upgradable_mutex> lock(mutex);
sharable_lock<interprocess_upgradable_mutex> lock2(mutex);
cv.wait(lock); // doesn't compile
cv.timed_wait(lock, deadline); // doesn't compile.
}
It is failing because boost doesn't define the following methods:
void interprocess_condition::do_wait(interprocess_upgradable_mutex
&mut);
bool interprocess_condition::do_timed_wait(const
syssrv_boost::posix_time::ptime &abs_time, interprocess_upgradable_mutex
&mut);
I was thinking of making a basic implementation like so:
Define a scoped_unlock class, which behaves just like scoped_lock except the
constructor unlocks and the destructor locks.
Then define the following:
inline void interprocess_condition::do_wait(interprocess_upgradable_mutex
&mut)
{
scoped_unlock<interprocess_upgradable_mutex> unlock(mut);
interprocess_mutex &internal_mutex = mut.m_mut;
scoped_lock<interprocess_mutex> internal_lock(internal_mutex);
this->wait(internal_lock);
}
inline bool interprocess_condition::do_timed_wait
(const syssrv_boost::posix_time::ptime &abs_time,
interprocess_upgradable_mutex &mut)
{
scoped_unlock<interprocess_upgradable_mutex> unlock(mut);
interprocess_mutex &internal_mutex = mut.m_mut;
scoped_lock<interprocess_mutex> internal_lock(internal_mutex);
return this->timed_wait(internal_lock, abs_time);
}
These functions simply do the following:
- unlock the exclusive lock on the interprocess_upgradable_mutex (which
is emulated with an internal interprocess_mutex)
- then lock the internal interprocess_mutex
- Call interprocess_condition::wait or interprocess_condition::time_ wait on
the implementation lock which does all the work
- unlock the internal interprocess_mutex
- relock the exclusive lock on the interprocess_upgradable_mutex
Intuitively, this should work.
Is there anything I missed that would make this an incorrect implementation?
Cheers,
-John
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net