Date: Mon, 28 Apr 2003 21:17:16 -0700 From: Peter Wemm <peter@wemm.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <20030429041716.A14182A7EA@canning.wemm.org> In-Reply-To: <Pine.GSO.4.10.10304282211190.28966-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > So I was glancing at rltd-elf, specifically lockdflt.c. There > seems to be an assumption that sigprocmask() can be used to > protect a thread from being swapped out. Am I reading this > right? I dont think so.. i386/lockdflt.c is just a simple spinlock that happens to work with libc_r. > There are no such guarantees with libpthread. A thread > will be swapped out whenever its quantum expires, and if > you've got higher priority threads, they will always run > before those of lower priority -- even if they are spinning. If this is happening, it would not suprise me. lockdflt.c seems more aimed at things like the M3 runtime. I think the real solution is to provide a way for a thread library to hook in its own lock routines that use something that is thread aware. However, this is probably easier said than done. It looks like we had one (dllockinit(3)), but its now deprecated... revision 1.46 date: 2000/07/08 04:10:30; author: jdp; state: Exp; lines: +135 -115 Solve the dynamic linker's problems with multithreaded programs once and for all (I hope). Packages such as wine, JDK, and linuxthreads should no longer have any problems with re-entering the dynamic linker. ... Spinlocks are the only kinds of locks that work with all thread packages. But on uniprocessor systems they can be inefficient, because while a contender for the lock is spinning the holder of the lock cannot make any progress toward releasing it. To alleviate this disadvantage I have borrowed a trick from Sleepycat's Berkeley DB implementation. When spinning for a lock, the requester does a nanosleep() call for 1 usec. each time around the loop. This will generally yield the CPU to other threads, allowing the lock holder to finish its business and release the lock. I chose 1 usec. as the minimum sleep which would with reasonable certainty not be rounded down to 0. ... i386/lockdflt.c: revision 1.8 date: 2002/07/06 20:25:55; author: jdp; state: Exp; lines: +2 -9 Remove the nanosleep calls from the spin loops in the locking code. They provided little benefit (if any) and they caused some problems in OpenOffice, at least in post-KSE -current and perhaps in other environments too. The nanosleep calls prevented the profiling timer from advancing during the spinloops, thereby preventing the thread scheduler from ever pre-empting the spinning thread. .... ... This is a short-term fix for a larger problem. The use of spinlocking isn't guaranteed to work in all cases. For example, if the spinning thread has higher priority than all other threads, it may never be pre-empted, and the thread holding the lock may never progress far enough to release the lock. On the other hand, spinlocking is the only locking that can work with an arbitrary unknown threads package. I have some ideas for a much better fix in the longer term. It would eliminate all locking inside the dynamic linker by making it safe for symbol lookups and lazy binding to proceed in parallel with a call to dlopen or dlclose. This means that the only mutual exclusion needed would be to prevent multiple simultaneous calls to dlopen and/or dlclose. That mutual exclusion could be put into the native pthreads library. Applications using foreign threads packages would have to make their own arrangements to ensure that they did not have multiple threads in dlopen and/or dlclose -- a reasonable requirement in my opinion. ==== Basically he's describing the exact scenario you're concerned about. The last paragraph suggests a better way. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030429041716.A14182A7EA>