Hello FPC,
Friday, July 1, 2011, 6:44:44 PM, you wrote:
HPD> This scenario was reflected in my example (bi-linked list update).
HPD> The very last sentence deserves clarification. When not *all*
HPD> assignments are protected by a CS, the use of Interlocked assignments
HPD> only can improve cache coherence, but it IMO *can not* prevent (logical)
HPD> race conditions. IMO Andrew observed just such race conditions,
HPD> resulting from a mix of sequential writes from multiple threads.
When not all assignements/reads are not protected by a CS (or similar)
there is not a problem of coherence, there is a logical problem. In
that case the use of interlocked operations only add overhead without
adding any kind of security/stability.
You can write lock free algorithms with interlocked operations, but
you can not write any other kind of procedures, usually more complex,
without a CS.
Tiny example:
Core/Thread 1:
--------------------
while true do begin
Critical.Enter;
a:=b;
b:=b+1;
if a=b then Raise Exception.Create('KBOOM!');
Critical.Leave;
end;
Core/Thread 2:
-------------------
while true do begin
InterlockedDecrement(b);
end;
This code will crash at a given time, maybe 1 millisecond, maybe 2
days, but it will crash.
Cache coherence is maintained by the hardware, interlocked only
provide atomicity. How the atomicity is provided is beyond the scope
of pascal and even the OS.
--
Best regards,
José
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
