Date: Thu, 22 May 2003 12:33:58 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO Message-ID: <XFMail.20030522123358.jhb@FreeBSD.org> In-Reply-To: <3ECCECE6.E1D7E8D0@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-May-2003 Terry Lambert wrote: > 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. We aren't talking about re-doing the work, we're talking about one CPU trying to walk the list while it's an inconsistent state and walking off into the weeds through a stale pointer. I.e, CPU 0 removes an item from the list while CPU 1 is walking over that item. Duh. > 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. Since the locks are only used on shared lists, they aren't present on lists that don't need protecting, whereas doing them in the queue macros itself would pessimize all lists, unless you want to have a runtime check and function call. Also, one thing you clearly have not noticed is that locks that cover lists usually also cover several other members of a related data structure, so you often need the lock anyways while you manipulate several data members of a structure. >> > 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... So what is your magic solution for making rtld thread-safe when looking up unresolved symbols on first reference? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030522123358.jhb>