[fpc-devel] LockFree Queue algorithm
darekm at emadar.com
Tue Jan 29 18:27:50 CET 2008
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:
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
Manual, Volume 3, the for more information on locking of caches.
More information about the fpc-devel