Date: Thu, 22 Mar 2001 10:59:42 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Tony Finch <dot@dotat.at> Cc: freebsd-smp@FreeBSD.org Subject: RE: Locked data-structures and delayed writes. Message-ID: <XFMail.010322105942.jhb@FreeBSD.org> In-Reply-To: <E14g6vW-00077j-00@hand.dotat.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Mar-01 Tony Finch 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. > > 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? Memory barriers. When we acquire a lock, we enforce a memory barrier to ensure that the data accesses to actually obtain the lock are obtained before we perform any 'sensitive' operations. Secondly, we use another memory barrier during the release to ensure that all 'sensitive' operations are finished before the lock is released. > 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. If the program doesn't need the data, who cares if it is lost? If the data is not program specific (e.g. kernel data structures) then the page won't be unmapped. :) However, it is actually a concern to make sure that if the data is still in the cache, it doesnt' get written out later when some other program is using this page. This can be handled in various ways depending on what cache architecture is being used. For an excellent treatment of this topic, see "Unix Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers" by Curt Schimmel ISBN 0-201-63338-8. > Tony. > -- > f.a.n.finch fanf@covalent.net dot@dotat.at -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.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?XFMail.010322105942.jhb>