Re: [boost] [thread] Roadmap for RW locks ?

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2006-11-02 11:23:32

On Nov 2, 2006, at 11:05 AM, Jeff Garland wrote:

> Howard Hinnant wrote:
>> On Nov 2, 2006, at 10:09 AM, Anthony Williams wrote:
>>
>>> Your sample adaptor has given me the idea of not having an explicit
>>> timed_lock
>>> function, but rather overloads of try_lock:
>>>
>>> bool try_lock(); // just try once
>>> bool try_lock(unsigned spin_count); // spin this many times
>>> bool try_lock(target_time_type target_time); // wait until the
>>> specified time
>>> bool try_lock(time_period_type wait_time); // wait for the
>>> specified period
>>
>> I like it.
>>
>
> Can I respectfully suggest time_duration_type instead of  
> time_period_type?
> That would bring the terminology in line with N1900/N2058.  I'm  
> assuming what
> you actually want to do is have user code that looks like this:
>
>   if (try_lock(seconds(3))) {...
>
>   if (try_lock(milliseconds(100))) { ...
>
> In boost date_time and N1900/N2058 time_period is an interval type  
> with a
> start time and an end time.  Oh, and if N1900 isn't persuasive enough,
> 'duration' happens to be the term ISO 8601 uses define a length of  
> time.

<nod> As far as I'm concerned this is implied.

On Nov 2, 2006, at 10:58 AM, Doug Gregor wrote:
> Are there conversions from integral types to target_time_type and/or
> time_period_type?
> If so, I would be quite surprised if try_lock(1000) spun 1,000 times
> before failing, rather than 1,000 milliseconds (for instance).

This works perfectly on a machine where 1 spin takes 1 millisecond! :-)

I think we're into brainstorming here and not specifying precise  
interfaces.  You guys are an iteration or two ahead of us.  But  
thanks for leading the way! :-)

-Howard