Re: [AD] public thread API

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2008-08-07, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Thu, 2008-08-07 at 09:07 +1000, Peter Wang wrote:
> > > Oh, something else:
> > > 
> > > int al_cond_timedwait(ALLEGRO_COND *cond, ALLEGRO_MUTEX *mutex,
> > >                       const ALLEGRO_COND_TIMEOUT timeout);
> > > 
> > > What about using "double timeout", and specifying it in seconds?
> > 
> > This reminds me of a similar decision in the events API that we
> > discussed, which I forgot to implement.  We should adopt the same
> > solution for al_cond_timedwait as for the events function.
> 
> Hm. In current SVN, I found this:
> 
> bool al_wait_for_event_timed(ALLEGRO_EVENT_QUEUE *queue,
>    ALLEGRO_EVENT *ret_event, float secs)

As I said, it's not implemented yet.

> > At any rate, it should be an absolute timeout as al_cond_timedwait()
> > *needs* to be called in a loop.  With relative timeouts you're
> > obliged to keep track of how long al_cond_timedwait() took
> > and subtract that for the next iteration of the loop.
> 
> Well, 
> 
> ALLEGRO_COND_TIMEOUT cond_timeout;
> al_cond_timeout_init(&cond_timeout, timeout);
> while(!check_condition() &&
>     !al_cond_timedwait(cond, mutex, &cond_timeout)) {}
> 
> vs.
> 
> double end_time = al_current_time() + timeout;
> while(!check_condition() && al_current_time() < end_time)
>     al_cond_timedwait(cond, mutex, end_time - al_current_time());
> 
> The second version seems more explicit to me, no extra struct, no extra
> function call, and a direct time comparison instead of a return value. 
> 
> But no strong preference, and I might be missing something..

The pthread_cond_wait man page has justification for an absolute timeout:

   Timed Wait Semantics
     An absolute time measure was chosen for specifying the timeout parameter
     for two reasons. First, a relative time measure can be easily implemented
     on top of a function that specifies absolute time, but there is a race
     condition associated with specifying an absolute timeout on top of a
     function that specifies relative timeouts. For example, assume that
     clock_gettime() returns the current time and cond_relative_timed_wait()
     uses relative timeouts:

	 clock_gettime(CLOCK_REALTIME, &now)
	 reltime = sleep_til_this_absolute_time -now;
	 cond_relative_timed_wait(c, m, &reltime);

     If the thread is preempted between the first statement and the last
     statement, the thread blocks for too long. Blocking, however, is
     irrelevant if an absolute timeout is used. An absolute timeout also need
     not be recomputed if it is used multiple times in a loop, such as that
     enclosing a condition wait.

Peter