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

["Gillius" <gillius@xxxxxxxxxx>]

On 4 Mar 2002 at 19:48, Eric Botcazou wrote:

> I think this mini-API is long overdue because most ports now use threads. It
> could be useful for the users, as well as internally in order to synchronize
> parts of the platform-independent code (especially timers).

I completely agree.  I think Allegro has been needing this for quite some 
time as even the most trivial of timers are not correct (x++) without a 
mutex.
 
> Here's the proposal:
> - non recursively lockable: in other words, Pthread-style mutexes, not
> WinThread-style mutexes.

I tried that myself with GNE, and it didn't work so well.  I started to use 
PTHREAD_MUTEX_RECURSIVE when I got tired of chasing down a couple of 
recursive locks, when all I had to do is change one line of code.  I didn't 
notice any significant loss of performance, and in Windows CriticalSections 
do it anyways.

> - minimal common subset functions: create/destroy, lock/unlock (2).

I agree.  Keep it nice and simple.

> (2) Is there a need for a try_lock() function ? Such a function would be
> natively supported by Pthreads and by Windows threads on NT kernels but not
> on Win9x kernels. In this latter case, it will have to be implemented by the
> Win32-specific code (by using an internal system mutex).

I've gotten through with GNE on not using try_lock, and I haven't seen a 
need for it, so it's definitely possible to get by without it.  If there is 
a penality for providing that support I would leave it out.

Gillius