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

Vinzent Höfler JeLlyFish.software at gmx.net
Wed Oct 27 23:16:57 CEST 2010


On Wed, 27 Oct 2010 22:52:03 +0200, Andrew Brunner  
<andrew.t.brunner at gmail.com> wrote:

> 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.

Are you counting up only? Then you can use the 32-bit version of the
InterlockedIncrement on the lower word only. If this turns out to be zero
(the new value is returned) after the operation, you know you also have to
increment the high word. Even with 30'000 transactions per second it takes
about 9 hours until the lower word will be zero again, so the probability
of a race condition happening here is very close to zero.

Well, you still need to stop any reader from using the value while you do
that. Assuming that your read frequency is much lower than the number of
transactions per second, it shouldn't be a big problem to lock out the
reader for a couple of nanoseconds.


Vinzent.



More information about the fpc-devel mailing list