Date: Sun, 13 Apr 2008 22:27:46 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Arthur Hartwig <Arthur.Hartwig@nokia.com> Cc: arch@freebsd.org Subject: Re: f_offset Message-ID: <20080413222626.X959@desktop> In-Reply-To: <480313A2.4050306@nokia.com> References: <20080412132457.W43186@desktop> <480313A2.4050306@nokia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Apr 2008, Arthur Hartwig wrote: > ext Jeff Roberson wrote: >> So I'm in the midst of working on other filesystem concurrency issues and >> that has brought me back around to f_offset again. I'm working on a method >> to allow non-overlapping writes and reads to proceed concurrently to the >> same file. This means the exclusive vnode lock can not be used to protect >> f_offset even in the write case. >> >> To maintain the existing semantics I'm simply going to add an exclusive >> sx_xlock() around access to f_offset. This is done inconsistently today >> which is fine from the perspective of the updates in most cases being >> user-space races. However, f_offset is 64bit and can not be written >> atomically on 32bit systems and so requires some extra synchronization >> there. > I'm not sure of the processor family constraints of the i386 builds, but the > Intel IA32 architecture manual says reads and writes of a quadword (64 bits) > aligned on a quadword boundary are atomic (Pentium and newer CPUs). Guess > that leaves out i386, i486 (any others?) Thanks. I hadn't seen that. Do you know which manual and section states this? I was intending to simply use cmpxchg8b but it sounds like that may not be necessary. We still have to handle other 32bit archs like powerpc and mips but I'm not sure if any of those are SMP. Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080413222626.X959>