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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Do you mean that, if a mutex is already locked, the decision whether
> to allow another lock depends on whether the would-be locker is the
> thread that locked in the first place (in which case it is allowed),
> or another thread (in which case it is blocked) ?

Exactly.

> In this case, and if Allegro does not provide an API for creating
> and using threads, but merely suggests using timers along with the
> mutex API, then I do not see the need for such recursive mutexes,

I agree that recursive locking is not really required in this particular
case.

> Also, it seems dodgy to me that a thread could lock multiple times
> a mutex. What kind of uses are there for this ?

The thread doesn't really lock the mutex multiple times. There is a count
attached to the mutex which is released only when the count gets back to
zero.

This simply allows easy nesting. For example, acquire_bitmap()/
release_bitmap() involves locking a mutex under Windows for non-memory
bitmaps, and drawing primitives automatically call the function pairs. Now
if you want to draw 1000 lines in a row, it is better (for performance
reasons) to put a global acquire_bitmap()/ release_bitmap() around the 1000
calls to line(). Supporting this requires no extra-code in acquire_bitmap()/
release_bitmap() because the thread doesn't need to care whether it already
locked the mutex or not.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx