[Lazarus] thread safe

[Andrew Brunner]

On Tue, Jun 28, 2011 at 2:32 PM, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> 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.