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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Hmm, I know Peter said verb/noun, but this is different to pthreads,
> and I at least will always get this the wrong way round if that is the
> case! (Just to prove the point to myself, I did it wrong below when
> typing this mail ;-) ).

I agree that Pthreads is a good model, but I think the verb/noun rule has
the priority.

> AL_MUTEX_INITIALISER
>   A macro used for initialising a mutex variable, eg:
> AL_MUTEX mutex = AL_MUTEX_INITIALISER;

That's again a pure Pthread-ism, that doesn't directly make sense in the
Win32 world (although Pthreads-win32 probably supports it, so we could
always defer actual initialization of the Win32 critical section until the
first lock, but IMHO this would unnecessarily complicates the code).

> AL_MUTEX* al_create_mutex(void)
>   Creates a new mutex object, which should be destroyed with
> al_destroy_mutex(). Returns 0 on error (out of memory).

I'd rather have 'int al_init_mutex(AL_MUTEX *mutex)' because this mimics
both Pthreads and Win32:
    pthread_mutex_init(&mutex, NULL);
    InitializeCriticalSection(&crit_sect);

> void al_destroy_mutex(AL_MUTEX*)
>   Frees any resources associated with a mutex. Should only be called on
> mutexes obtained with al_create_mutex(). Don't use the mutex after
> destroying it.

Ok. Perhaps it can return an 'int' though, so that we can detect attempts to
destroy a locked mutex.

> void al_lock_mutex(AL_MUTEX*)
> void al_unlock_mutex(AL_MUTEX*)
>   Locks/unlocks a mutex. Note that Allegro mutexes are not recursive,
> so if you lock the same mutex twice within a thread, you will cause a
> deadlock. [These functions could fail in some rather ridiculous
> circumstances; we could reflect this with a return value?]

Ok. As for the return value, Win32 doesn't return any for instance.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx