2

C++0x allows to lock on a mutex until a given time is reached, and return a boolean stating if the mutex has been locked or not.

template <class Clock, class Duration>
bool try_lock_until(const chrono::time_point<Clock, 
                    Duration>& abs_time);

In some contexts, I consider an exceptional situation that the locking fails because of timeout. In this case an exception should be more appropriated.

To make the difference a function lock_until could be used to get a timeout exception when the time is reached before locking.

template <class Clock, class Duration>
void lock_until(const chrono::time_point<Clock, 
                Duration>& abs_time);

Do you think that lock_until should be more adequate in some contexts? if yes, on which ones? If no, why try_lock_until will always be a better choice?

roalz
  • 2,699
  • 3
  • 25
  • 42
Vicente Botet Escriba
  • 4,305
  • 1
  • 25
  • 39
  • 3
    Is anything in this question specific to try_lock_until? A situation is "exceptional" or not, according to (a) whether the callee can return a meaningful value, and (b) whether the caller can continue. We can't comment on (b), so we can't tell you whether or not throwing an exception is a sensible response to `try_lock_until` returning false. Any caller may respond to any function that returns a false value, by throwing an exception. The C++ standard libraries don't throw much except for out-of-memory and cases where no value can be returned (e.g. failed dynamic cast to reference). – Steve Jessop May 01 '10 at 23:38
  • @Steve I think that your comment could be a reason to not needing lock_until. Could you add an answer? my question is have you throw a timeout exception when try_lock_until return false. If yes on which contexts? – Vicente Botet Escriba May 01 '10 at 23:53

1 Answers1

2

Can't you just check the return value and throw your own exception?

if ( ! my_lock.try_lock_until( my_start_time ) ) {
    throw realtime_error( "Couldn't start in time!" );
}

Also, a quick look through the threading and exceptions libraries in the FCD doesn't show any time-related exception classes, so there's no type in std:: for lock_until to naturally throw.

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
  • @Potato I see that you have followed the advice I give to Steve. You should let Steve to do it himself. – Vicente Botet Escriba May 02 '10 at 06:55
  • @Vic I didn't copy the idea from the comments, if that's what you mean. I can make this CW if you'd feel better. – Potatoswatter May 02 '10 at 07:15
  • @Potatowatter Well I accept that you can have the same idea. I agree that the interface provided by the standard is minimal and allows the user to do whatever she wants. It is normal you don't find lock_until because it is part of my question. The question is do you prefer the code you written or a specific function that throw a common exception. – Vicente Botet Escriba May 02 '10 at 07:40
  • @Vicente: Personally, I would define the function to generate the exception as soon as I defined the new exception class, assuming there were several such deadlines to miss. I dislike copy-paste code. But overspecified functions that only get called in one place are also bad. – Potatoswatter May 02 '10 at 08:22
  • +1 I have finally accepted your answer as, as the user can always implement it easily. but I really think however that the addition of exception based timed locks open a window for mush more friendly features. – Vicente Botet Escriba May 06 '10 at 22:44