On 21-May-2003 Terry Lambert wrote: > John Baldwin wrote: >> >> According to chapter 12 of the "Go Solo 2" book, this is a bogus thing >> >> to do. Callers are required to take a critical section over the calls >> >> to the dl* functions because the dlerror() function uses a static buffer >> >> that can be overwritten in a multi-threaded environment. >> > >> > Sadly, that insight doesn't seem to have influenced the development >> > practices of a number of major application vendors :-(. >> >> As Peter has mentioned before, simply locking calls to dlopen() in the >> application is not sufficient since every time you have to resolve a >> symbol when doing a call to a function for the first time, you hit the >> same data structures and need the locks in those cases as well. Assuming >> I recalled all that correctly. > > 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. > 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_at_ list though. -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/Received on Wed May 21 2003 - 03:38:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:08 UTC