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-05 13:31:09

----- Original Message ----- 
From: "mur" <mur_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Monday, January 05, 2009 2:30 PM
Subject: Re: [Boost-users] [thread] locking and time

> 
> 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_lock<boost::shared_mutex> lock(mtx_);
        // ...
        ts_g(lock);
    }
    g() {
        unique_lock<boost::shared_mutex> lock(mtx_);
        ts_g(lock);
    }
    ts_g(unique_lock<boost::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