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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Here's the proposal:
> - fully portable: on platforms that don't support threads (DOS, Unix w/o
> pthreads, Darwin), do nothing. In particular, not a replacement for
> internal "DOS-style semaphores"
> - inner-process synchronization only: not required to be visible outside
> the process, hence can use the lightest solution on every platform (e.g
> critical sections under Windows).
> - non recursively lockable: in other words, Pthread-style mutexes, not
> WinThread-style mutexes.
> - minimal common subset functions: create/destroy, lock/unlock (2).

OK, this proposal seems to be more or less agreed on.

Now to the form:
- should we prefix everything with al_ ? (I assume yes from here).

- as the mutexes are not recursively lockable, I think using
acquire_mutex()/release_mutex() for the lock/unlock functions might be
misleading, given that acquire_bitmap()/release_bitmap() are recursively
callable. Hence I propose al_lock_mutex()/al_unlock_mutex().

- should we use a BITMAP-style API:

    AL_MUTEX *mutex;
    mutex = al_create_mutex();
    al_lock_mutex(mutex);
    al_unlock_mutex(mutex);
    al_destroy_mutex(mutex);

or (Pthreads and Winthreads-style API)

    AL_MUTEX mutex;
    al_init_mutex(&mutex);
    al_lock_mutex(&mutex);
    al_unlock_mutex(&mutex);
    al_destroy_mutex(&mutex);  ?

AL_MUTEX will probably be a small-sized structure:

    typedef struct {
        int locked;
        void *handle;
    } AL_MUTEX;

--
Eric Botcazou
ebotcazou@xxxxxxxxxx