[SDL] semaphores made from mutexes?

Carsten Griwodz Carsten.Griwodz at KOM.tu-darmstadt.de
Wed Apr 19 01:38:37 PDT 2000


Hi !

> Could people who know threads and semaphores take a look at this
> implementation and let us know if it has flaws?  It's also in SDL CVS,
> but not guaranteed to stay.

As for as I know, the answer is "yes, it has a flaw", sorry.

If initial_value > 1, SDL_SemPost() will (potentially) be called by a
thread that has not originally locked the mutex.
My pthreads book tells me that the behaviour is "undefined" by POSIX;
I haven't read the standards and can confirm the book's statement.
Our experience is that this works under Solaris 2.6 anyway, but that it
fails under Linux 2.2 (hang on unlock) or AIX 4.3 (doesn't unlock).

Besides, I believe that SDL_CreateSemaphore() should leave the wait_lock
in the unlocked state, and that SDL_SemValue() should be protected by
locking count_lock.

If you want to use only the pthreads interface and not rely on realtime
POSIX, I have attached a bit of C++ code that uses pthread_mutex_t and
pthread_cond_t.
The MNOSem is untested (lack of time), just written to show what I
consider a safer approach for waiting. If you look at the code, don't
be confused by the name MNSem, it's actually a condition variable and
the name is a historical error on our part.

If I should implement this with mutexes only, I would be in trouble.
Maybe something with a thread, some Unix pipes and select?

Tschuess,
   Carsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: osem.tgz
Type: application/gzip
Size: 1764 bytes
Desc: osem.tgz
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20000419/2b1f416a/attachment-0008.bin>


More information about the SDL mailing list