[Lazarus] thread safe

[Andrew Brunner]

On Tue, Jun 28, 2011 at 9:59 AM, Michael Schnell <mschnell at lumino.de> wrote:

> I fully agree. With the RTL/LCL, the MUTEX is encapsulated in the
> TCtriticalSection Object (one MUTEX per instance. And of course, here, a
> single instance is necessary to be used for all accesses to the pointers).
> And as the Mutex already contains the Full Fence memory barrier and (as
> discussed over in the fpc list) the function calls to Enter and Leave
> prevents the compiler from caching any of the intermediate pointer values in
> registers at a wrong point in time, I don't see why CriticalSection would
> not be the correct way to go and work as expected. (OTOH using atomic
> interlocked ASM  instructions does not help as all pointers need to be
> updated in a single atomic operation).

Your assumption would be incorrect.  The system doesn't do anything
but decrease the spincount of the criticalsection object to make sure
the variable is valid.  As stated before by numerous people, a
CriticalSection does not apply to variable assignments.  It just
blocks entrance to code blocks unit the lock is released.

> But the original claim was that the implementation with Critical sections
> failed on a multi core engine and interlocked instructions helped.

It was an claim.  It is an assertion.  It's cause - due to core cache
as documented on wikipedia.

> This is why I suggested that there is some kind of bug.

You're free to suggest anything.  Just be prepared to learn or teach -
but back it up with facts no opinions.