From owner-freebsd-smp Thu Mar 22 9:29:50 2001 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DB49137B71C for ; Thu, 22 Mar 2001 09:29:47 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2MHTkw05202; Thu, 22 Mar 2001 09:29:46 -0800 (PST) Date: Thu, 22 Mar 2001 09:29:46 -0800 From: Alfred Perlstein To: Tony Finch Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Locked data-structures and delayed writes. Message-ID: <20010322092946.M9431@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dot@dotat.at on Thu, Mar 22, 2001 at 03:23:02PM +0000 X-all-your-base: are belong to us. Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Tony Finch [010322 07:24] wrote: > > 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. Ah, the glass is not only half empty, but it will most likely shatter and slice your lips off kinda guy... Yes, I know a couple of people like that. :) > 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? Usually one of two things: 1) any locked op forces the CPU to flush all writes before it completes 2) there are explicit write/read barrier opcodes that people who design lock primatives are expected to use. > A related question, but perhaps more implausible, is what happens if a > page is unmapped from underneath a delayed write. This is particularly > pathological if the destination page was mmapped and the program is > exiting: the write may be lost. Yes, this is why there's such a thing as a 'tlb' shootdown, which I think requires IPI (interprocessor interrupt) to notify that the system pagetables are being changed. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message