I suspect I'm talking about something quite similar -- user-level
threads, but enough kernel-level contexts to keep all the CPUs active.
> Fine, but if you are talking about threads (of any kind) that don't
> have individual stacks, then it doesn't have much bearing on
> pthreads. Such threads are very interesting in their own right,
> though.
Stacks are allocated automatically on demand. To be more precise, all
threads have a local stack frame when they run, but whenever an object
returns to the "main loop" (for want of a better term), its stack frame
can be reused -- there is no stack state to preserve. But if it blocks
within the object's own functions, the stack frame is locked by that
thread.
In practice, this means what I'm proposing has to combine efficient
object-based thread dispatch with efficient pthreads-style threading.
I think it can be done.
> > The intention is (1) that a typical fast "schedule calling 50,000
> > objects' `think()' methods" list+heap scheduler runs most of the objects
> > efficiently (without individual stack frames); (2) some processing
> > continues even while paging;
>
> Your sleeping-process-signals-another-process idea gives this, and is
> easy to implement. (And possibly could be used for a nice
> implementation of POSIX aio).
It's not quite enough unfortunately. The problem of what to do when a
blocked process unblocks is tricky, if you want performance as well as
nice implementation.
> > (3) a few objects can use operating system
> > services and get their own stack frame (on demand), while being able to
> > use the same mutex/semaphore/message services as the 50,000 simulated
> > objects.
>
> I can see why you would want this. But why should a pthreads
> implementation provide mutex, etc. facilities that can be used by
> programs well outside the scope of pthreads? If you can do it in
> LinuxThreads with no significant cost to other LinuxThreads progams,
> go ahead. But if you can't, then it's not going to be attractive to
> people doing things that don't resemble heavily-threaded simulations.
The simulated objects thing I brought up was to indicate just how fast I
feel "context switching" (if you can call it that) is intended to run,
concurrently with heavier LinuxThreads-style threads.
[ Aside: I am working with a group that has been using LinuxThreads to
do numerical calculations and data acquisition over a network.
Context switching performance, as well as network latency absolutely
sucks, even though there are only a small number of threads active at
a time.
To make that application work well, user-level threads are being
implemented. (Not the same as what I'm proposing). These _are_ threads
with stacks, so could in principle be used in place of a LinuxThreads
mechanism. But they are only interested in their application, so it
will not be a replacement.
From what I have seen, this means LinuxThreads performance has ways to
go before its performance is good enough. I think (but I'm not certain
yet), that the mechanisms we've been talking about can be used to get
that performance and still have pthreads-like semantics. ]
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/