[fpc-devel] Re: systemh.inc InterLockedIncrement64 (var Target: int64)

Florian Klaempfl florian at freepascal.org
Thu Oct 28 10:11:09 CEST 2010


Am 28.10.2010 10:02, schrieb Jeppe Johansen:
> Den 27-10-2010 23:14, Florian Klämpfl skrev:
>> Am 27.10.2010 22:52, schrieb Andrew Brunner:
>>> My SCS project which is a scalable unified collaboration and
>>> communication server that uses counting for transactions and network
>>> consumption across all implemented protocols.  Bytes, when aggregated
>>> can clearly exceed the 2GB limitation within seconds.  Partial
>>> transactions (PTX) can exceed over 30,000 per second and full
>>> transactions (TX) are typically 50% of that... But these numbers need
>>> to add up.  Meaning the aggregate TX count must be of some proportion
>>> of the PTX otherwise they are bogus.
>>>
>>> Int64 or QWord w/o locking or CAS is a serious issue for me.  I
>>> absolutely need this feature or my transaction/byte counts will be off
>>> per node per cluster and can lead to misinformation in the consumption
>>> reports.
>>>
>>> For the time being though I can restrict the scale on i386
>>> architecture since I tried to re-map the methods in the system.inc
>>> file to no avail.  It appears that FPC does not include the
>>> Interlocked*64 methods inside the RTL.
>> I propose to add the 64 bit CAS for all 32 bit archs (if available): the
>> 64 bit CAS instruction on a 32 bit target makes makes a lot "lock-free"
>> algorithms simpler.
>>
>> So you can build your 64 bit interlockedincrement yourself (there is no
>> native on any 32 bit target I'am aware of).
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> CMPXCHG8B works on probably most x86 architectures

Yes. That's what I wrote ;) because there is no interlockedincrement,
one can use the 64 Bit CAS (implemented by CMPXCHG8B) to do the
interlockedincrement64. But I don't want to provide a
interlockedincrement64 on 32 bit platfroms by default because it
requires cas with a while loop so it actually polls.



More information about the fpc-devel mailing list