Just a note, I forgot to initialize the reference count in the "mutex"
conditional code. Oops. 
Anyway, one thing I figured out is that it is possible to have a single
thread started “reference count” times instead of "reference count"
threads started during an SDL_condSignalAll(). (In the "mutex"
conditional code, that is.)
A way around that is to have a ring buffer like the event queue uses and
hold a seperate mutex for each waiter. That way we are guaranteed to
start all the threads once when doing an SDL_condSignalAll().
Just some additional thoughts.
Paul Braman
@Paul_Braman
Anyway, one thing I figured out is that it is possible to have a single
thread started “reference count” times instead of "reference count"
threads started during an SDL_condSignalAll(). (In the "mutex"
conditional code, that is.)
I assume you are thinking of the case where a thread is signaled and
begins to wait again even before another thread finished executing its
unlocks. You should be able to get around this by having two mutexes
WaitSignal would look like this:
LockMutex( FallProtector );
reference++;
LockMutex( WaitProtector );
reference–;
LockMutex( ExitProtector );
UnLockMutex( ExitProtector );
UnLockMutex( FallProtector );
and SignalAll would look like:
LockMutex( FallProtector );
while( reference != 0 ){
UnLockMutex( WaitProtector );
}
UnLockMutex( ExitProtector );
UnLockMutex( FallProtector );
Thoughts?
Stuart
LockMutex( FallProtector );
reference++;
LockMutex( WaitProtector );
reference–;
LockMutex( ExitProtector );
UnLockMutex( ExitProtector );
UnLockMutex( FallProtector );
and SignalAll would look like:
LockMutex( FallProtector );
while( reference != 0 ){
UnLockMutex( WaitProtector );
}
UnLockMutex( ExitProtector );
UnLockMutex( FallProtector );
Thoughts?
This wouldn’t work.
When the waiter locked the FallProtector it doesn’t unlock it when it
attempts its WaitProtector lock. THe signaling thread comes along and
attempts to obtain a FallProtector lock but is block by the waiting
thread.
The idea is reasonably nice but I think using a seperate mutex for each
waiter might simplify the implementation. (In other words, if I’ve
restarted a thread I would like it to go immediately without having to
wait until I am done restarting other threads. The reference count
adjustment really doesn’t allow that but having all threads wait until I
am done restarting everything seems a little more contentious.)
Paul Braman
@Paul_BramanOn Sat, 13 Nov 1999, Stuart Anderson wrote:
The idea is reasonably nice but I think using a seperate mutex for each
waiter might simplify the implementation. (In other words, if I’ve
restarted a thread I would like it to go immediately without having to
wait until I am done restarting other threads. The reference count
adjustment really doesn’t allow that but having all threads wait until I
am done restarting everything seems a little more contentious.)
Okay, my only objection to your scheme is that it sets a limit on the
number of threads. Why not use a data structure that can expand
dynamically, linked lists in this case?
Stuart
Okay, my only objection to your scheme is that it sets a limit on the
number of threads. Why not use a data structure that can expand
dynamically, linked lists in this case?
Actually, I wasn’t completely honest. I was avoiding a race condition.
I’ve come up with a (what I consider) nice way around it that allows as
many threads to wait on a condition as you like.
I am in the middle of banging out three sets of functions: one using
POSIX threads, one using Unix semaphores, and one using mutexes.
The POSIX code will work for those systems where POSIX threads are
supported. The Unix semaphore code will work on those systems supporting
the semget()/semop() type system calls. The mutex code will use SDL_mutex
functions for systems like Win32 and BeOS. (Yes, there is actually a
reason I don’t use SDL_mutex functions on systems supporting Unix
semaphores.)
I’ve looked over the code long and hard and hopefully eliminated all the
race conditions so give it a whirl when I post it.
Paul Braman
@Paul_BramanOn Sun, 14 Nov 1999, Stuart Anderson wrote: