Doug Gregor <dgregor@cs.indiana.edu> 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