Bug Fixes
Bug description: if multiple threads are waiting to read a message from
a DFStandardQueue (pop), then when they are stopped only the first
thread manages to be terminated. This is due to the behavior of
pthread_cond_wait function, which is used to implement the pop method
on the DFStandardQueue.
pthread_cond_wait man page:
"A condition wait (whether
timed or not) is a cancellation point. When
the cancelability enable state of a thread is set to
PTHREAD_CANCEL_DEFERRED, a side
effect of acting upon a cancellation request while in a condition wait
is that the mutex is (in effect) re-acquired before calling the first
cancellation
cleanup handler. The effect is as if the thread were unblocked, allowed
to execute up to the point of returning from the call to
pthread_cond_timedwait() or pthread_cond_wait(), but at that point notices the
cancellation request and instead of returning to the caller of
pthread_cond_timedwait() or pthread_cond_wait(), starts the thread cancellation
activities, which includes calling cancellation cleanup handlers."
In practice this means that the mutex acqired by the pthread_cond_wait
fuction upon cancellation of the first thread was never released, thus
not allowing all other threads to acquire it and terminate.
Fix: A new class DFLock has been created. The constructor receives a
pthread_mutex_t or DFMutex pointer as argument and locks the mutex. The
destructor unlocks the mutex. Locking a mutex using this class
instanciated in the stack makes sure that the mutex is unlocked once
the instance goes out of scope.
The DFLock class is now used throughout the DFTHreads package.