Re: [AD] Mini-synchronization API proposal for 4.1.x

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2002-03-27, Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:
> > To me, this is unacceptable, and very misleading.  IMHO, I now think
> > that mutexes were the wrong choice.
> 
> Do you mean that the mutex API is a wrong choice, or that using mutexes to
> ensure thread safety is a wrong choice ?

The latter.  Actually, mutexes for *thread* safety is fine.  But that
these AL_MUTEX things behave differently on different platforms, and
have the potential to cause nasty and subtle bugs, annoys me. 

eg. "This is a mutex, except when it's not."  Then after reading
that, you have to remember that constantly.  Would you not cringe if
you found something like that in someone else's API?

> > Allow temporary disabling of _user_ callbacks, and during the disabled
> > period, delay pending callbacks by putting them in a queue.  IIRC,
> > this is similar to what Michael did with the SIGALRM driver.
> 
> Ok, so basically you want a single system lock ? 

Yes.

> How do you ensure atomicity for the callbacks ? Do you require that a
> al_system_lock()/al_system_unlock() pair be placed inside the user callback
> function too:
>   user callback (secondary thread)
>     void callback(void)
>     {
>        ...
>        al_system_lock();
>        /* the primary thread blocks if it reaches al_system_lock() */
>        al_system_unlock();
>     }
> or does any callback automatically lock the system lock ?

Not sure.  Both methods have their merits.  I think it depends if
locking is expensive.  If it is, then it should be the user's choice.

Also, I would make it so that only one timer/keyboard/mouse/etc
callback is called at a time.  This follows directly from the queue.

> > Threaded ports should be fine, too.  One possibility is for a separate
> > thread to wait on a condition variable, signaled when it should start
> > running callbacks from the queue.  If another thread needs to run a
> > callback, it either adds it to the queue or calls it directly.
> > Probably it would be better to _always_ queue.
> 
> Do you mean you want a dedicated thread that flushes the queue ?
[snip]

Yes, but that was only an idea for an implementation.  You could do it
any other way, too.