Hi, I wonder if you can help me. I'm using the Shmem library (v0.92) and I'm trying to use a shared_timed_mutex with a scoped_timed_lock. This seems to work until the mutex is about to go out of scope. Then my program just hangs. It seems that it can not unlock the mutex. I tried issuing a "unlock" function call on the lock object and that hangs as well. Could anyone confirm if the shared_timed_mutex works at the moment. Thanks for you help. Steve.
Hi again,
I got some more info on the behaviour I'm seeing.
Within the locked critical region I do a timed wait on a condition variable.
The mutex falls to unlock only if the timed wait on the condition variable
timed out. If the condition is met, then the mutex unlocks when it goes out
of scope.
Maybe the shmem library is using a single flag for the status of a mutex and
condition variable (seems unlikely though).
Thanks,
Steve.
On 24/05/06, Steven Wooding
Hi,
I wonder if you can help me.
I'm using the Shmem library (v0.92) and I'm trying to use a shared_timed_mutex with a scoped_timed_lock. This seems to work until the mutex is about to go out of scope. Then my program just hangs. It seems that it can not unlock the mutex. I tried issuing a "unlock" function call on the lock object and that hangs as well.
Could anyone confirm if the shared_timed_mutex works at the moment.
Thanks for you help.
Steve.
Steven Wooding(e)k dio:
Hi again,
I got some more info on the behaviour I'm seeing.
Within the locked critical region I do a timed wait on a condition variable. The mutex falls to unlock only if the timed wait on the condition variable timed out. If the condition is met, then the mutex unlocks when it goes out of scope.
Hi Steve, Can you give me some more information about this? Platform, OS, compiler... If you could do a small test case it would be even better. Regards, Ion
Hi Ion,
I'm on 64-bit Linux (SuSe 10.0) using the Intel compiler 9.0 or gcc 4.0.2.
Here is some rough code that may better explain what I'm trying to do:
int Fun1( bufferIndex, expectedProgressState, newProgressState, timeoutTime)
{
boost::shmem::shared_timed_mutex::scoped_timed_lock lock( mutex,
timeoutTime)
if (lock.locked() == true)
{
while ( mp_bufferIndex[bufferIndex].m_progressState
!= expectedProgressState)
{
if (
mp_bufferIndex[bufferIndex].m_bufferCondition.timed_wait( lock, timeoutTime)
== false)
{
// Timed out on condition
return timedOut;
}
}
// Change the progress state
{
else
{
// mutex timed out
return timedOut;
}
return success;
}
I hope this makes sense. In this test, the value of the
expectedProgressState is never true, in order to force the timeout.
Basically I obtain the mutex before we even wait on the condition variable.
Let me know if I've gone wrong with the pattern I'm using.
Cheers,
Steve.
On 24/05/06, Ion Gaztañaga
Hi Steve,
Can you give me some more information about this? Platform, OS, compiler... If you could do a small test case it would be even better.
Regards,
Ion
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Here is some rough code that may better explain what I'm trying to do:
(...) come code (...)
Logically the code seems good, but the problem is that shared_condition is only limited to work with shared_mutex. The shared_timed_mutex suffers the same limitation as boost::mutex (I basically ported the code from inter-thread to inter-process). This is because in boost::timed_mutex and boost::shmem::shared_timed_mutex the mutex is imitated with a condition variable + a mutex + a boolean and there is no real pthread_mutex_t to share with condition variable. Looking for boost::thread's documentation: template<typename ScopedLock> bool timed_wait(ScopedLock& lock, const boost::xtime& xt); Requires: ScopedLock meets the ScopedLock requirements. Effects: Releases the lock on the mutex object associated with lock, blocks the current thread of execution until readied by a call to this->notify_one() or this->notify_all(), or until time xt is reached, and then reacquires the lock. Returns: false if time xt is reached, otherwise true. Throws: lock_error if !lock.locked() So you can only use scoped_lock and no scoped_timed_lock. I will try to include this in the next documentation. Regards, Ion
participants (2)
-
Ion Gaztañaga -
Steven Wooding