Date: Fri, 23 May 2003 16:22:17 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) Message-ID: <Pine.GSO.4.10.10305231618410.8151-100000@pcnet1.pcnet.com> In-Reply-To: <3ECE3FBE.7EBE5ED5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 May 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > This is just because rtld-elf is not thread safe (or written > > so that locks are not needed as you claim). > > No. There is plenty of code that falls into this category; as > soon as you finish fixing rtld, you will reveal other problems. > Mark my words; you cannot make user space thread safe for all > eventualities, with the user process never having to know > anything about mutexes that the pthreads model expects the user > program to hold in order to ensure against race conditions. We can easily correct for dlfoo() being called by different threads concurrently, so I don't include that in being "thread-safe". As it stands now, rtld-elf is not thread-safe even without calls to dlfoo(). > > > The second of these is that the libkse model is M:N, with N being > > > defaulted to 1. If you want more kernel threads, you have to ask > > > > N is defaulted to the number of CPUs that you have. Libkse > > will create as many KSEs as there are CPUs (or whatever > > kern.threads.virtual_cpu is set to); these will be KSEs > > that run scope process threads. Scope system threads > > get their own KSE/KSEG pair without regard to number of > > CPUs or kern.threads.virtual_cpu. > > > > Trying to exceed the number of CPUs with kern.threads.virtual_cpu > > will not work unless you also set kern.threads.debug=1. You > > really shouldn't need to do this, but we use it for testing > > and debugging. > > This is handy to know; so basically, my expectation from > reading the code around PTHREAD_SCOPE_SYSTEM was correct: > a single CPU system with PTHREAD_SCOPE_PROCESS (the default) > can still get itself blocked in the kernel by a single > blocking call (as in the USB bulk read device issue). If I am reading you correctly, then no. Scope process threads will block in the kernel, but upcalls will be made to the originating KSE and new threads will be scheduled. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10305231618410.8151-100000>