----- Original Message -----
From: "mur"
Hello Vicente,
2) (recursive timed) shared mutex: Is it not possible to lock with a period of time instead of ptime?
shared mutex are not recursive.
So I had to check if I there is no place where another function which also aquires a lock is called within the locked scope.
You can this at two levels: Let me say if f call g and both lock the same mutex, you can define a 'private' ts_g that has a unique_lock as parameter f() { unique_lockboost::shared_mutex lock(mtx_); // ... ts_g(lock); } g() { unique_lockboost::shared_mutex lock(mtx_); ts_g(lock); } ts_g(unique_lockboost::shared_mutex& lock) { // this pretends that a unique_lock on mtx_ has been locked. ts_g(lock); } HTH.
But maybe I should keep the old code. Now I use
a code based on boost::threads from http://paulbridger.net/read_write_lock
which I modified in order to work with timed locks.
I would prefer an implementation that follows the interface of the shared_mutex, unique_lock, shared_lock and upgradable_lock. Why not try to implement recursive_shared_mutex with the interface of shared_mutex?
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.
If I modify the time in order it is one hour earlier, I guess the lock could take one hour. This is even a bigger a problem with the sleep function of the threads library. So it is not possible to change the system time to earlier values for certain applications.
You are right. I have take a look on the C++0x standard and they are changing the specification of all the timed operation with duration parameters to use monotonic clocks (If I understand it a monotonic clock can not be changed in oposition to a system clock). This address directly your issue. I hope that the Boost libraries working with duration types will on its turn modify the implementation but I think that the Boost.Chrono library will be needed. Vicente