Date: Thu, 27 Dec 2001 23:10:20 +0100 (CET) From: Michal Mertl <mime@traveller.cz> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alfred Perlstein <bright@mu.org>, John Hanley <jh_@yahoo.com>, <arch@FreeBSD.ORG> Subject: Re: 64 bit counters Message-ID: <Pine.BSF.4.41.0112272240370.96716-100000@prg.traveller.cz> In-Reply-To: <200112271941.fBRJfCF01253@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Dec 2001, Mike Smith wrote: > > :Why do I think it never becomes wrong? Generally I'm adding rather small > > :value (<1e6 or so) to 64 bit counter. When one addition overflows less > > :significant 32 bits, several next additions don't overflow. > > : > > :u_int64_t+=u_long is: > > :addl %eax,(u_int64_t) ; this is atomic, right? > > :adcl $0,4(u_int64_t) > > : > > :If interrupt occurs in between these two instructions, then the less > > :significant halt is right and more significant will be fixed after the > > :execution returns to second instruction. Even if the interrupt modified > > :the value, we can expect (read - be sure) it didn't modify the more > > :significant half. > > > > You are absolutely right. The carry will only be set on the addl > > which overflows the 32 bit counter and will not be set on any of > > the other addl's that might be occuring just before, inbetween the > > two instructions, or just after. So only one of those will cause the > > msb to increment. > > > > For UP the addl instruction is atomic. For SMP we still have to lock the > > bus cycle. Something like this: > > > > lock; addl %eax,(u_int64_t) > > lock; adcl $0,4(u_int64_t) > > This is all well and good, but not portable. Aren't all other architectures we support 64 bit? On i386 even present form (32 bit addition) isn't atomic (no lock involved). On i386 for 64 bits the compiler generates the code above (without locks) and on 64 bit platforms I expect it would generate something at least similarly atomic like 32 bit addition on i386 we use today (both stable and current). On i586 we can have 64 bit atomic operations with cmpxchg8b. On Aplha I think the long is 64 bit so counters are already 64 bit. Anyway the code probably should be rewritten to use mutexes or atomic operations or whatever. I'll look at some current sources and maybe I'll be able to understand what are all these locks, mutexes, msleep and so on. In the time being I'll keep my naive patch to add the functionality to stable (it happens to work (probably only in 99.99999% of time and bit less on SMP)). > Sorry folks. 8( Not at all. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.41.0112272240370.96716-100000>