Messages in this thread | | | Date | Sun, 21 Feb 1999 10:27:40 +0000 | From | Jamie Lokier <> | Subject | Re: Asynchrony (was Re: Locking a process or thread onto a specific CPU) |
| |
David Wragg wrote: > > I don't know about typical pthreads programs. The "fast, really I mean > > fast" threads that I'm talking about is indeed user-on-kernel-threads. > > Alexander was talking about FreeBSD's user-level threads, though.
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/
| |