Hi, ----- Original Message ----- From: "Ernst Murnleitner" To: 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#th...). It document the types but not the variables. In http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html#thread.lo... 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_lockboost::mutex lock(mtx, boost::defer_lock); // the mutex is not locked here or boost::mutex mtx; mtx.lock(); boost::unique_lockboost::mutex lock(mtx, boost::adopt_lock); // lock will unclock the mutex on destruction or boost::mutex mtx; boost::unique_lockboost::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