On Tue, Jun 28, 2011 at 2:32 PM, Hans-Peter Diettrich <[email protected]> wrote: > Andrew Brunner schrieb: > >>> In a bidirectionally linked list up to 4 pointers have to be updated >>> together, whenever an element is inserted or removed. This leaves much >>> room >>> for race conditions, that cannot be cured by protecting every single >>> pointer. Instead the entire chain must be protected, by a MUTEX or other >>> synchronization means. And then it's only a *convention*, which object or >>> memory block shall be protected by a MUTEX, no memory barrier prevents >>> access without obtaining the MUTEX first. Kind of a memory barrier can be >>> established by putting the list object (head) into a TThreadList, >>> *provided >>> that* no code will retain references to list elements after releasing the >>> list object. >> >> I had a similar issue once. > > Above is my comment on your example ;-)
The above comment has nothing to do with my "example". My example was the one with 2 lines of code being executed by two different cores under the same thread protected within a criticalsection. My experience though, was shared where I "happened" to have a memory barrier in place, and experienced a problem with order or stale values that was solved by using InterlockedExchange calls. > Why do you see a need for Interlocked updates, when only one thread can > access the list at the same time? Primarily because I want to enforce core cache updates to the values. > IMO Interlocked updates are fine for self-contained values, where the use of > critical sections would be overkill. But when multiple variables have to be > updated without interruption (synchronously, atomically), the entire data > object should be protected against concurrent access. > I see it as a matter of coding discipline, and how to make disobedience as > impossible as possible ;-) > Obedience is not germane to the topic of this particular issue of core cache and interlockedexhange. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
