Re: Lockless 63-bit Counter
From: Terje Mathisen (terje.mathisen_at_hda.hydro.com)
Date: 03/11/04
- Next message: Michael Brown: "Re: Lockless 63-bit Counter"
- Previous message: Matt Taylor: "Re: [OT] Athlon XP VS. Pentium 4"
- In reply to: Matt Taylor: "Re: Lockless 63-bit Counter"
- Next in thread: Matt Taylor: "Re: Lockless 63-bit Counter"
- Reply: Matt Taylor: "Re: Lockless 63-bit Counter"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 11 Mar 2004 17:36:21 +0000 (UTC)
Matt Taylor wrote:
> Isn't it still possible for a thread to read [ebx+4] before another thread
> rolls the counter over, or do cache semantics preclude this? I know only one
> processor can have it cached due to the lock prefix (forces Exclusive
> state), but I wonder if that is any guarantee. It is still possible to fail
> on a single-CPU machine as a context switch is possible between the load and
> the locked add + exchange.
Updates can happen at _any_ time, but if you first read the high half,
and then XADD the low, without getting the sign bit set, then you have
to be safe, i.e. there's no way another process can first XADD after you
(to get a wrap), and then update the high half, before you read it the
first time.
When you do find that the counter has overflowed, then you have to
restart from the beginning.
Anyway, this is one of those places where MONITOR/MWAIT can help, by
making it easier for the process that's updating the counter to get
private access, instead of being bombarded by all the other cpus.
Terje
-- - <Terje.Mathisen@hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
- Next message: Michael Brown: "Re: Lockless 63-bit Counter"
- Previous message: Matt Taylor: "Re: [OT] Athlon XP VS. Pentium 4"
- In reply to: Matt Taylor: "Re: Lockless 63-bit Counter"
- Next in thread: Matt Taylor: "Re: Lockless 63-bit Counter"
- Reply: Matt Taylor: "Re: Lockless 63-bit Counter"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|