On 7/2/07, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
rick68 <rick68@gmail.com> writes:
>
>
> If I use boost::timed_mutex::scoped_timed_lock to do lock (m_locked is true)
>
> ==<boost/thread/detail/lock.hpp>==
> void boost::detail::thread::scoped_try_lock<boost::timed_mutex>::lock()
> {
> if (m_locked) throw lock_error();
> lock_ops<TimedMutex>::lock(m_mutex);
> m_locked = true;
> }
> ========================
>
> lock will throw lock_error, so I thought maybe to use while-loop will be
> fine.
This is a different m_locked. The m_locked in timed_mutex is the variable
associated with the mutex --- is the mutex locked by any thread? The m_locked
in the scoped_timed_lock member function you quoted above is associated with
the scoped_timed_lock --- does this scoped_timed_lock object own the
associated mutex?
Oops, this is the key pointer, I didn't detect timed_time has a m_locked.
I confuse they two.
> I just read about thread code and test it.
>
> Can use condition and mutex to substitute for timed_mutex, but I want to
> know how to use timed_mutex.
timed_mutex is just a mutex, but with timeouts on the locks --- if the mutex
is locked when you try and acquire it, you can pass in a timeout to specify
how long to wait before giving up trying to acquire the lock. Look at
test_timedlock in libs/thread/test/test_mutex.cpp for example usage.
Thank you very much!
I got it~ :D
Rick