Re: user-space threads

[nferrier at tapsellferrier dot co dot uk]

"Boehm, Hans" <hans_boehm@hp.com> writes:

> It's certainly possible to implement threads entirely in user space, at least on most Unix systems.  It has been done many times.  The garbage collector supports (or at least supported) one such system: Xerox PCR.
> 
> I would be opposed to making a user-level threads package the
> default on any system that had another, more standard threads
> implementation, mostly for compatibility reasons.  Mixing thread
> implementations is a mess.  (I assume you have heard about the NPTL
> effort to replace Linuxthreads?  If not,
> https://listman.redhat.com/pipermail/phil-list/2002-September/000013.html
> seems to be a starting point, though the documentation situation
> still seems to be suboptimal.  I understand it is claimed to solve
> the 10K thread problem.)
> 
> If the platform doesn't already support threads, I don't see a
> fundamental problem with user-level threads.
> 
> The garbage collector is currently structured so that it can run on
> an arbitrary thread, and consume fairly substantial amounts of stack
> space.  It could probably be made to run in a special thread at some
> small cost in GC overhead.  But I suspect a lot of other library
> routines that can be invoked by gcj have a similar problem, though
> perhaps to a lesser extent.  I'm not sure how far you can really
> reduce maximum thread stack sizes, nor how you would support
> thread-stack interleaving for native code.
> 
> You certainly have to teach the GC about whatever changes you make
> to thread stack layout, since it has to trace them.  The
> thread-stopping code would probably also be affected.  But I don't
> think any of this is insurmountable.  Some of it probably gets
> easier and faster.
> 
> Hans
> 
> > -----Original Message-----
> > From: Adam Megacz [mailto:adam@megacz.com]
> > Sent: Wednesday, October 23, 2002 11:20 AM
> > To: java@gcc.gnu.org
> > Subject: user-space threads
> >
> >
> >
> > Is it possible to implement gcj's threading entirely in userspace,
> > using nonblocking I/O and alarm()?
> >
> > One of the reasons that a lot of server programs are moving towards
> > event-loop, nonblocking-io and away from thread-per-request is that
> > threads are "expensive".  Most of this "expensiveness" is just a
> > result of OS implementors not thinking that people would ever want to
> > form 10,000 threads -- so often they'll use data structures like
> > linked lists of threads and perform a linear scan through the list for
> > some operations.
> >
> > It turns out that there's nothing inherently expensive about threads
> > except that each thread gets its own stack on a seperate page, which
> > cause memory cache thrash.  I'm investigating a technique for getting
> > threads to *share* a stack -- interleaving the stack frames from
> > different processes on a single page.  Actually, I'd probably have a
> > few stacks, each with a fixed frame size (8 byte, 32 byte, 64 byte,
> > etc).  Java turns out to be an ideal language for this, because its
> > stack frames are really tiny (no stackvars).
> >
> > Anyways, userspace threads would be a straightforward way to implement
> > this.  They'd also be useful for platforms that have alarm() but don't
> > have threads (lots of embedded platforms).
> >
> > Does the gc make any assumptions about threading that would break if I
> > used this technique?

Are you guys aware of the NGPT project at IBM? It's an M:N threading
library based on Ralf's pth project. It has many of the advantages of
user space threads (ie: an abstraction over kernel threads) without
requriing specific library support (it provides a modified pthreads
library).


Nic