libkse and SMP (was Re: USB bulk read & pthreads)

[Daniel Eischen]

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