Date: Thu, 22 May 2003 08:29:42 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO Message-ID: <3ECCECE6.E1D7E8D0@mindspring.com> References: <XFMail.20030521083829.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > > That's an order of operations problem, not a locking problem. Just > > like a lot of the simple queue.h structures that are unnecessarily > > being locked around modificiations because the macros aren't being > > rewritten to make the updates atomic. > > Unless you plan to use expensive atomic operations and memory barriers > to ensure in-order operation pessimizing all the lists that don't need > protecting you are going to need to protect shared lists. Please do > remember that writes from one CPU are not guaranteed to be visible to > other CPU's in program order. You don't care if another CPU re-does the work, so long as it re-does it atomically. That makes it thread safe without the introduction of locks. Introducing locks introduces "expensive atomic operations and memory barriers"; redoing it introduces an extra function call of overhead that doesn't matter and is less expensive. > > It's a really bad idea to imply a locking policy in something as > > fundamental as the runtime linker code, unless you expect to be > > able to replace the primitives at compile/link/runtime at some > > point. > > Unless I'm mistaken we aren't the first set of folks to add locking > to the runtime linker. I'm sure that there is already a suitable > bikeshed over this on the threads@ list though. Just because your friend jumped off a cliff... -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECCECE6.E1D7E8D0>