From owner-freebsd-smp Thu Mar 22 9:41:54 2001 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 7F20937B71A for ; Thu, 22 Mar 2001 09:41:51 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f2MHbiG20456; Thu, 22 Mar 2001 11:37:44 -0600 (CST) (envelope-from jlemon) Date: Thu, 22 Mar 2001 11:37:44 -0600 From: Jonathan Lemon To: Alfred Perlstein Cc: Jonathan Lemon , dot@dotat.at, smp@FreeBSD.ORG Subject: Re: Locked data-structures and delayed writes. Message-ID: <20010322113744.T82645@prism.flugsvamp.com> References: <200103221639.f2MGdgW18437@prism.flugsvamp.com> <20010322093158.N9431@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010322093158.N9431@fw.wintelcom.net> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 22, 2001 at 09:31:58AM -0800, Alfred Perlstein wrote: > * Jonathan Lemon [010322 08:44] wrote: > > In article you write: > > > > > >I've been having an interesting discussion elsewhere with someone > > >about the problems caused by delayed writes within the CPU. He's of > > >the general opinion that everything is broken and can be very > > >enlightening when explaining why he thinks this but he can also be > > >frustratingly vague. > > > > > >Anyway, the question at hand is what happens if two threads on > > >different CPUs are accessing the same locked data structure when the > > >CPU delays writes to RAM, i.e. > > > > > > acquire_lock(s); > > > modify(s); > > > release_lock(s); > > > > > >Things are very broken if the write can be delayed until after the > > >lock is released. What prevents that? > > > > Uhm. Why would things be broken simply because the write is delayed? > > This isn't a trick answer; if you don't subsequently read the location, > > then why would it matter if the write is delayed? (modulo writes to > > device memory; in these cases, you probably want to mark the writes as > > uncacheable) > > > > Now, if your modify involves doing a read of the location, then that > > is a different question. > > Heh, what if your write to 's' happens after lock release and without > it 's' is not consistant? You need a write barrier. Well, cache coherency and memory ordering are two different things. If the architecture has a relaxed memory ordering (say, release consistency) then you will need a write barrier to enforce ordering of the lock with respect to modify(). But that is a different question from just a delayed write. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message