Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Mar 2001 09:31:58 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Jonathan Lemon <jlemon@flugsvamp.com>
Cc:        dot@dotat.at, smp@FreeBSD.ORG
Subject:   Re: Locked data-structures and delayed writes.
Message-ID:  <20010322093158.N9431@fw.wintelcom.net>
In-Reply-To: <200103221639.f2MGdgW18437@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Mar 22, 2001 at 10:39:42AM -0600
References:  <local.mail.freebsd-smp/E14g6vW-00077j-00@hand.dotat.at> <200103221639.f2MGdgW18437@prism.flugsvamp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Jonathan Lemon <jlemon@flugsvamp.com> [010322 08:44] wrote:
> In article <local.mail.freebsd-smp/E14g6vW-00077j-00@hand.dotat.at> 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.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
Represent yourself, show up at BABUG http://www.babug.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




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