[Lazarus] thread safe

[Hans-Peter Diettrich]

Henry Vermaak schrieb:
> On 28/06/11 15:47, Hans-Peter Diettrich wrote:
>> Henry Vermaak schrieb:
>>
>>
>>> You'll have to read the generated assembler for Windows critical
>>> sections. My hunch would be that they use memory barriers, too.
>>
>>  >>
>> When a critical section object is owned, the only other threads affected
>> are the threads that are waiting for ownership in a call to
>> EnterCriticalSection. Threads that are not waiting are free to continue
>> running.
>> <<
>>
>> I don't see anything like memory barriers here.
> 
> Quoting from 
> http://msdn.microsoft.com/en-us/library/ms686355%28v=VS.85%29.aspx
> 
> The following synchronization functions use the appropriate barriers to 
> ensure memory ordering:

Sorry for my ignorance :-(

I couldn't find a definition for memory barriers before, and confused it 
with persistent access locks (or visibility).

OTOH I still wonder what exact use and effects the various MB 
instructions have. One requirement is data consistency of the 
implementation of all synchronization mechanisms (mutex...), across all 
cores and caches, i.e.:
>     Functions that enter or leave critical sections
>     Functions that signal synchronization objects
>     Wait functions
>     Interlocked functions
This is so obvious, that it IMO doesn't require further discussion.

Another aspect seems to be the synchronization of *all* data, in *all* 
caches. Is this correct, or do I expect too much?

In detail I stumbled over the remark, that these instructions signal 
*the compiler* (which compiler? which processor?) to do something 
special. This may be related to the "volatile" discussion?

DoDi