[fpc-devel] SMP > 2 core Cache issue with Posix threads

Hans-Peter Diettrich DrDiettrich1 at aol.com
Fri Jul 1 18:44:44 CEST 2011


Vincent Snijders schrieb:

>>> Michael Schnell wrote:
>>>> In another topic (now closed) Andrew described that a code similar to
>>>> HansPeter's example did run correctly on a dual core machine, but produced
>>>> errors on a machine with more cores.
>>> I've not been reading every message. Definitive URL?

I cannot provide an URL (from old Thunderbird), so let me cite the 
essential part of Andrew's message:

 >>
Simply protecting a loop with a futex is not sufficient.  Assigning
variables in a multi-threaded environment is not sufficient.

Interlocked/Exchange/ExchangeAdd/Increment features must be used
whenever dealing with variables (with at least one exception)  In my
experience arrays of boolean are atomic.

I ran tests on a HexCore AMD system which had unexplained anomalies
with pointers in an bidirectional linked list.  I replaced all the
pointer assignments with InterlockedExchange and the system worked
flawlessly.  Some of the assignments were taking place in a
criticalsection (btw).
<<

This scenario was reflected in my example (bi-linked list update).

The very last sentence deserves clarification. When not *all* 
assignments are protected by a CS, the use of Interlocked assignments 
only can improve cache coherence, but it IMO *can not* prevent (logical) 
race conditions. IMO Andrew observed just such race conditions, 
resulting from a mix of sequential writes from multiple threads.

IMO a linked list can not work flawlessly, until at least a 
multiple-read-exclusive-write lock is used. While an exclusive-write 
lock can ensure list consistency, every unsynchronized reader will be 
fooled by concurrent changes to the list structure :-(

Consider what will happen when an (unsynchronized) reader determined an 
list node, before or after which a new node shall be inserted. When the 
write-synchronized update will happen, the list structure already can 
have changed, so that the referenced node can have changed its position 
in the list, or can have been moved into a very different list :-(

DoDi




More information about the fpc-devel mailing list