From owner-freebsd-smp Thu Mar 22 7:24: 4 2001 Delivered-To: freebsd-smp@freebsd.org Received: from hand.dotat.at (inch.demon.co.uk [194.222.223.128]) by hub.freebsd.org (Postfix) with ESMTP id 33E0E37B71D for ; Thu, 22 Mar 2001 07:24:01 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14g6vW-00077j-00 for freebsd-smp@freebsd.org; Thu, 22 Mar 2001 15:23:02 +0000 From: Tony Finch To: freebsd-smp@freebsd.org Subject: Locked data-structures and delayed writes. Message-Id: Date: Thu, 22 Mar 2001 15:23:02 +0000 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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? 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. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message