Date: Thu, 22 Mar 2001 10:39:42 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: dot@dotat.at, smp@freebsd.org Subject: Re: Locked data-structures and delayed writes. Message-ID: <200103221639.f2MGdgW18437@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-smp/E14g6vW-00077j-00@hand.dotat.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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. The ia-32 architecture uses a strong cache coherence model, so that writes to the same location appear to be seen in the same order by all processors (write serialization). So even if the memory write in modify() above is delayed until after the release_lock() call, any reads from that location will return the new data. On other architectures, you may need to explicitly manage the cache coherence yourself. >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. On the alpha, the write buffers are physically addressed, so if the virtual address mapping is removed, it will not affect the delayed write, since the write does not require the page tables. I'm not sure what Intel does; I would guess probably the same thing. I would assume that if some architecture uses virtually addressed blocks in a write buffer (!!), then part of the task of a TLB flush be to complete the delayed write before removing the mapping. -- Jonathan 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?200103221639.f2MGdgW18437>