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. 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.
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 should do a ticket on the Trac system for each issue.
Yes, I submitted them. Greetings Ernst