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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-02 11:22:25

Doug Gregor <dgregor_at_[hidden]> writes:

> 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
>
> Sorry, naive user just woke up and saw this fly by...
>
> 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).

I would expect time_period_type and target_time_type to have explicit
constructors. The usage I imagine is something like:

mutex m;
m.try_lock(milliseconds(1000)); // wait 1s
m.try_lock(seconds(1000); // wait 1000s
m.try_lock(date_time(2006,11,2,16,9,27)); // wait until 16:09:27 on 2nd November 2006
m.try_lock(1000); // spin 1000 times

I'm not averse to

m.try_lock(spin(1000)); // spin 1000 times

but I'm not sure it's necessary. Just specifying a plain number begs the
question "1000 what?", and the docs will make it clear that it's a spin count.

Consider:

    sleep(5);
    Sleep(5);

One waits 1000 times as long as the other. It's not obvious to the casual
observer what the time units are; you have to know your API.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk