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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> > - 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.

Ho ! I thought Pthreads didn't natively support recursive locking, so
Allegro would have to emulate it on top of them. If they do support it, then
I agree with you that recursive locking is better. Moreover,
acquire_bitmap()/release_bitmap() supports this semantics.

> > (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.
>
> 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.

I agree, all the more easily if we decide on recursive locking.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx