Comments on: Condition variables and monitors for Delphi

By: Tobias Gurock

Tobias Gurock — Fri, 27 Feb 2009 07:34:35 +0000

I’m aware of instructions reordering and cache related problems. However, I still think the pthreads guys got the code right. For example, they are aware of possible race conditions:

“In the line where you state, “else if ( nWaitersBlocked > nWaitersGone ) { // HARMLESS RACE CONDITION!” there is no race condition for nWaitersGonebecause nWaitersGone is never modified without holding mtxUnblockLock. You are correct that there is a harmless race on nWaitersBlocked, which can increase and make the condition become true just after we check it. If this happens, we interpret it as the wait starting after the signal.”

I agree that the code is pretty complex and difficult to verify but the equivalent C implementation has shipped with pthreads for several years now.

By: René

René — Thu, 26 Feb 2009 20:35:51 +0000

The thing is even if the mutual exclusion would be guaranteed, there is no guarantee that the memory write-cache is synchronized between physical processors, cores or hyperthreads unless you are using the SAME synchronization mechanism every time the same variable is accessed. (See also http://msdn.microsoft.com/en-us/magazine/cc163715.aspx)

By: Tobias Gurock

Tobias Gurock — Thu, 26 Feb 2009 07:25:54 +0000

Yes, the implementation is complex, maybe too complex. If I recall correctly there was a discussion about this particular case on the pthreads list/forum. There’s a link in Threads.pas to some implementation notes from the pthreads developers. Good suggestion with TMonitor.Wait. In .NET/Java, Wait throws an exception if the current thread does not hold the lock, I think that would be a good feature to add to Threads.pas as well.

By: René Grob

René Grob — Wed, 25 Feb 2009 21:18:28 +0000

Well, may be my comment above was a bit exaggerated. My point of view is that everything what is not clearly threadsafe is not threadsafe. I have some doubts concerning the function “WaitConditionVariable”. It just seems to be a too complicated implementation. In the function “InternalPulseConditionVariable” the variable ACond.WaitersBlocked is read and written without the guarding lock of “ACond.BlockSemaphore”. I don’t see a consistent synchronization mechanism to access “ACond.WaitersBlocked”. Besides TMonitor.Wait(..) should check that it has the ownership of the critical section or enforce it by explicitly reentering it.

By: Tobias Gurock

Tobias Gurock — Wed, 25 Feb 2009 09:28:27 +0000

Hello René,

thanks for your comment. Can you give any code lines which contain a race condition? Would be much appreciated. This code is basically a port of the pthreads win32 condition variables implementation.

By: René Grob

René Grob — Wed, 25 Feb 2009 08:53:07 +0000

I looked at the source code. I have the impression that a lot of non-atomic operations are used to simulate an atomic operation. There are a lot of possibilities of race conditions. I consider the code to be NOT THREADSAFE. There is an API function “SignalAndWait” which is atomic, but unfortunately it can only be used with a Mutex not with a CriticalSection.

By: Tobias Gurock

Tobias Gurock — Sat, 27 Sep 2008 21:09:57 +0000

To your comment above, the producer signals the condition variable only when the related predicate/condition is already true. It actually shouldn’t matter at all (performance differences aside as mentioned by your discussion) if the signal is issued within the lock or after – except if the internal implementation requires holding the lock.

While the producer adds an item to the queue, the whole section is locked and the client cannot enter the same lock. Once the item has been added, the mutex is unlocked and the consumer can enter the critical section. Since the condition is true, it shouldn’t matter if the producer is preempted right before signaling the condition variable because the consumer does not wait anyway.

Being able to signal the condition variable after releasing the lock seems to be an implementation specific feature since in Java and .NET, for example, you are required to hold the lock while signaling the condition variable. The new condition variable API which ships with Windows Vista, on the other hand, supports this feature as well (See SleepConditionVariableCS and WakeConditionVariable):

You can wake other threads using WakeConditionVariable or WakeAllConditionVariable either inside or outside the lock associated with the condition variable. It is usually better to release the lock before waking other threads to reduce the number of context switches.

As a side note, I just learned that the new Delphi 2009 finally got support for condition variables with a new TMonitor record. Also, if you are developing against Windows Vista, it’s probably a better idea to directly use their new condition variable API.

By: Tobias Gurock

Tobias Gurock — Fri, 26 Sep 2008 11:29:09 +0000

Thanks the link Ivan, I will look into it. As far as I understand it, the PulseAll is not required to be inside the lock (according to the pthreads implementation).

By: Ivan Levashew

Ivan Levashew — Fri, 26 Sep 2008 11:21:22 +0000

I’ve found a discussion on this topic:

http://thread.gmane.org/gmane.os.ecos.general/13018

By: Ivan Levashew

Ivan Levashew — Wed, 24 Sep 2008 11:43:12 +0000

Producer might Pulse condvar when consumer has owned mutex but is not waiting on condvar yet. Consumer will have to wait the whole timeout or infinitelly.

Timeout in ThreadsDemo is 250 so it won’t cause serious problems in this particular case.