Hi,
----- Original Message -----
From: "Ernst Murnleitner"
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