Date: Thu, 22 Mar 2001 09:29:46 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Tony Finch <dot@dotat.at> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Locked data-structures and delayed writes. Message-ID: <20010322092946.M9431@fw.wintelcom.net> In-Reply-To: <E14g6vW-00077j-00@hand.dotat.at>; from dot@dotat.at on Thu, Mar 22, 2001 at 03:23:02PM %2B0000 References: <E14g6vW-00077j-00@hand.dotat.at>
next in thread | previous in thread | raw e-mail | index | archive | help
* Tony Finch <dot@dotat.at> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010322092946.M9431>