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

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."