Re: [AL] Multithreading Timers

[George F. <gf...@us...>]

On Sat, Apr 14, 2001 at 05:14:14PM -0400, Gillius wrote:
> > On Fri, Apr 13, 2001 at 11:07:23AM +0200, Eric Botcazou wrote:
> > > A solution could be of course to implement a minimal synchronization API
> > > (namely mutex).
> 
> We could do that.
> 
> But what about just saying that timer functions may be called from a 
> different thread than the main execution thread therefore the user should 
> make the functions atomic?  If the user wishes more than an atomic function 
> then they should use some syncronization library such as pthreads, which is 
> cross-platform.

It could be done that way.  I think the question is really
whether Allegro should provide routines to help the user here or
not.  It's hard to answer; to some extent this locking is only
necessary when the timers *are* multi-threaded, and could be
harmful when they're not -- if your main code locks a mutex and
then the timer can't get a lock on it, it will deadlock, unless
you arrange for the timer to return immediately and catch up
later on.  If the mutexing is done by Allegro then it can more
easily turn it on or off depending on what the threading model
is.  Or if it's done by the user, Allegro could let the user
know whether it should be done or not.

Would Windows pthreads be usable for this, considering that the
actual threading inside Windows Allegro is not done using
pthreads?

George

-- 
Random project update:
06/03/2001: AllegroGL 0.0.10 released at http://allegrogl.sourceforge.net/
	Six months' worth of changes, including Mingw32 support!