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