Re: [Boost-users] [thread] locking and time

Subject: Re: [Boost-users] [thread] locking and time
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-01-02 13:03:07

Hi,
----- Original Message ----- 
From: "Ernst Murnleitner" <mur_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Wednesday, December 31, 2008 10:24 PM
Subject: [Boost-users] [thread] locking and time

> 
> Hello,
> 
> I have some questions about threads. It would be very nice if somebody could
> clarify.
> 
> 1) recursive_timed_mutex: It is possible to use a time period for locking of a
> recursive_timed_mutex by using the approprioate timed_lock(). But there is not
> lock class with such a constructor? 
You are right. The standard includes 
    template <class Duration>
    unique_lock(mutex_type& m, const Duration& rel_time);

> 2) (recursive timed) shared mutex: Is it not possible to lock with a period of
> time instead of ptime?
shared mutex are not recursive.

You are right. The folowing should be added
    template<typename TimeDuration>
    bool shared_mutex::timed_lock_shared(TimeDuration const & relative_time);
    template<typename TimeDuration>
    bool shared_mutex::timed_lock(TimeDuration const & relative_time);

> 3) change of system time: What happens in a timed_lock if the system time is
> advanced by e.g. one hour? Is there a difference of using ptime or time_period?
I supose that the lock will expire. I don't think there is any difference because the relative time interface uses the absolute time one.

> 4) read/writer mutex: if there are some recursive locks by one thread and this
> thread should become the writer, do I run in a deadlock?
There are no recursive  read/writer mutex in Boost.Thread.

> 5) What is the meaning of the various ..._lock_t (e.g. )? Is there a
> documentation?

The Boost.Thread library documents this partially (http://www.boost.org/doc/libs/1_35_0/doc/html/thread/synchronization.html#thread.synchronization.locks.unique_lock.constructor_adopt). It document the types but not the variables. In 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html#thread.lock.unique
you can find a more information

"Some lock constructors may take tag types, which describe what should be done with the mutex during the lock's construction. 

struct defer_lock_t  {}; // do not acquire ownership of the mutex
struct try_to_lock_t {}; // try to acquire ownership of the mutex
                         // without blocking
struct adopt_lock_t  {}; // assume the current thread has already
                         // obtained mutex ownership and manage it

extern const defer_lock_t   defer_lock;
extern const try_to_lock_t  try_to_lock;
extern const adopt_lock_t   adopt_lock;

 "

You use them as follows:

    boost::mutex mtx;
    boost::unique_lock<boost::mutex> lock(mtx,  boost::defer_lock);
    // the mutex is not locked here
or
    boost::mutex mtx;
    mtx.lock();
    boost::unique_lock<boost::mutex> lock(mtx,  boost::adopt_lock);
    // lock will unclock the mutex on destruction
or
    boost::mutex mtx;
    boost::unique_lock<boost::mutex> lock(mtx,  boost::try_to_lock);
    // here the mutex can be lock or not, you need to check with lock.owns_lock()

You should do a ticket on the Trac system for each issue.

Best,
Vicente