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

[Vinzent Höfler]

On Wed, 27 Oct 2010 23:26:00 +0200, Andrew Brunner  
<andrew.t.brunner at gmail.com> wrote:

> On Wed, Oct 27, 2010 at 4:16 PM, Vinzent Höfler
> <JeLlyFish.software at gmx.net> wrote:
>> 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.
>
> Yes.  Only counting up in this case *but* one of my other stats is
> UPTIME.  Meaning we want to brag about how long the application is
> running w/o re-starting :-)  So restarting the app every time the
> counter rolls over, just isn't feasible for this application.

I didn't say "restart", I said "lock out the reader for a moment".
Maybe it's easier to grasp if I put it in some pseudo-code:

-- 8< --
Lock_Readers;

if InterlockedIncrement (Lower_32_Bit) = 0 then // Counter just rolled  
over.
begin
    // !!! Race condition if the counter rolls over twice while doing this.
    //     But with a 32 bit counter and 30'000 counts per second this
    //     can only happen if this code needs several /hours/ to execute.

    InterlockedIncrement (Upper_32_Bit);
end;

Unlock_Readers;
-- 8< --

So you're updating the value without locking and only need to lock out
the readers once in nine hours or so to ensure they /always/ get a
consistent value.


Vinzent.