[fpc-devel] LockFree Queue algorithm

[Dariusz Mazur]

Florian Klaempfl pisze:
> DarekM schrieb:
>   
>> Florian Klaempfl pisze:
>>     
>>> An if is unimportant, more important is the number of locked operations,
>>> especially on multi core systems they might eat hundreds of clock cycles.
>>>   
>>>       
>> There are atomic operations, the should not  eat much more than ordinal
>> INC or ADD,
>>     
>
> If course they are. They require no more a bus lock as in 486 times but
> a synchronization of all caches for this particular memory location.
>   
We don't need  wait to synchronize caches. It will be done by hardware.
And i think synchronize cache with ram don't eat hundreads clock cycles.
And CMPXCHG  has automatic locking asserted, as normal instruction can't 
persist so long (Intel don't mention about this)
This is also use to implement semaphores (suggest from Intel) , thus 
should be save and fast.




Form intel about caching: 
http://www.intel.com/design/processor/manuals/253668.pdf

Intel Architecture Compatibility
Beginning with the Pentium Pro processor, when the LOCK prefix is 
prefixed to an instruction
and the memory area being accessed is cached internally in the 
processor, the LOCK# signal is
generally not asserted. Instead, only the processors cache is locked. 
Here, the processors cache
coherency mechanism insures that the operation is carried out atomically 
with regards to
memory. Refer to Section 7.1.4., Effects of a LOCK Operation on Internal 
Processor Caches in
Chapter 7, Multiple-Processor Management of the Intel Architecture 
Software Developers
Manual, Volume 3, the for more information on locking of caches.


Darek