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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
