Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Apr 2008 18:49:33 +1000
From:      Arthur Hartwig <Arthur.Hartwig@nokia.com>
To:        ext Jeff Roberson <jroberson@jroberson.net>
Cc:        arch@freebsd.org
Subject:   Re: f_offset
Message-ID:  <48031A9D.3050806@nokia.com>
In-Reply-To: <20080413222626.X959@desktop>
References:  <20080412132457.W43186@desktop> <480313A2.4050306@nokia.com> <20080413222626.X959@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
ext Jeff Roberson wrote:
>
> 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?  
Intel 64 and IA-32 Architectures Software Developer's Manual Vol 3A: 
System Programming Guide, Part 1, section 7.1.1 Guaranteed Atomic 
Operations. You can download this (and other volumes of the Intel 
Architecture manuals) from 
http://www.intel.com/products/processor/manuals/index.htm

> 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.
Do you also have to handle i386 and i486?
>
> Jeff




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48031A9D.3050806>