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.