Date: Fri, 14 Oct 2005 20:30:00 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! Message-ID: <20051014102959.GB7346@cirb503493.alcatel.com.au> In-Reply-To: <20051014091004.GC18513@uk.tiscali.com> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2005-Oct-14 10:10:04 +0100, Brian Candler wrote: >I'd be grateful if you could clarify that point for me. Are you saying that >if I write > > long long foo; > ... > foo++; > >then the C compiler generates code for 'foo++' which is not thread-safe? >(And therefore I would have to protect it with a mutex or critical section) foo++ is not normally thread-safe even if foo is an int or pointer. Typical iA32 code looks like: addl $1,foo This is only thread-safe in a UP environment. Typical RISC code looks like: load foo,%reg add $1,%reg store %reg,foo This is not thread-safe. Note that the compiler may keep foo in a register for an extended period unless you convince the compiler not to. Especially on RISC processors, the compiler will normally spread the load/add/store to try and avoid pipeline stalls. If you share foo between two threads, you need to use atomic operations (see <machine/atomic.h>), mutexes or critical sections on all updates. Note that you can do atomic 64-bit operations on iA32 (except 80386 and 80486) using a locked cmpxchg8b in a loop. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051014102959.GB7346>