Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net