On Wed, 27 Oct 2010 23:26:00 +0200, Andrew Brunner
<andrew.t.brun...@gmail.com> wrote:
On Wed, Oct 27, 2010 at 4:16 PM, Vinzent Höfler
<jellyfish.softw...@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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
