Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?

[Farid Hajji]

> > > It seemed that the most tricky parts were (i) creating more kernel
> > > threads on demand, to avoid deadlocks, and (ii) to get signal
> > > handling and per thread signal masks right.
> > 
> > Creating more kernel threads on demand would just mean assigning
> > more kernel threads to the multiplexer/scheduler. The hairy problem,
> > as I'm currently understanding it, is that we must ensure that at
> > least one kernel thread acts as a garbage collector (or if you prefer
> > as a watch dog) that would wake up kernel-threads that deadlocked
> > because the user-threads, that were multiplexed on it themselves
> > deadlocked in a unforseen manner. Hmmm...
> 
> I don't quite understand you here. It's not the kernel's or the
> library's job to fix deadlock-bugs in user code (ok, it would be nice
> if it did that, but I don't think it's common). The problem is as
> follows: Say there are N kernel threads, and M>N user threads. Of the
> N kernel threads, most are hanging waiting for i/o, while some is
> blocking on a mutex. The mutex is currently locked by the N+1:th user
> thread, which isn't currently assigned a kernel thread.
Aha, yes; now I understand the problem. But it still boils down to
reserving at least one kernel thread that would have to detect this
or other similar situations and notify the user-level scheduler to
do something about it. If the user-level scheduler could detect this
itself, that would not be a problem at all. Therefore an external
live (=kernel) thread is needed to kick in.

> I'm not sure I get the scenario quite right, but the problem is that
> in order to get progress, the N+1:th has to be assigned to a kernel
> thread so that it can run until it releases the mutex, and in some
> situations, the way to do that is to start one more kernel thread.
Hmmm... does this really resolve the problem here? Sure, starting one
more kernel thread would resolve this special case, but what if this
new thread also becomes hogged by user-level threads that would also
block on other mutexes? Quite interesting...

> > (ii): Aww, signal handling _is_ a difficult part in every thread
> > implementation. But we're talking about a low-level thread package
> > here, that will _not_ be based upon a Unix-like system.
> 
> Ok. A was under the impression that the aim was for pthreads
> conformance. I'm not sure exactly how signal aware you have to be to
> say that you are pthread conformant, but at least in a unix-like
> environment, you'd want it to do the right thing.
> 
> On the other hand, signals are implemented very differently on the
> hurd than on unix, which may make the problem easier to solve. And
> even a thread package with broken signaling behaviour would be a
> useful thing to have.
That was the idea.

> I don't really know these things well, the above is based on my
> reading of the Solaris thread paper some time ago.
The code in FreeBSD's libc_r (Birrel's uthreads library) is really
instructive here. I'd urge everyone interested in threading issues
to have a look at it. It may even be included in OSKit, but don't
have an OSKit-copy on this machine to verify it right now.

> /Niels

Thanks,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.