On Wed, 7 Aug 1996 20:45:04 -0400, "Theodore Y. Ts'o" <tytso@mit.edu>
said:
> From: peter@ifm.liu.se (Peter Eriksson)
> I see one problem with this 16bit "thread-ID" idea - it's not
> impossible one would need more than 65536 concurrent threads,=20
> and what would one do then? Let's try to avoid stepping into the
> 640KB-is-more-than-anyone-would-ever-need trap again...
> I'm sure you can construct a proof-by-counter example that's it's
> possible that a program could actually try to create 65536 concurrent
> threads. I'd really like to see, however, an example of when you'd
> actually really want to *use* 65336 threads. People have raised the
> example of transputers where you have more than 64k computers ---
> however, in these cases, you *won't* be sharing memory, so you wouldn't
> be using separate threads anyway. (The thought of trying to do memory
> cache coherency checking across 64k processor makes me shiver....)
Quite. KSR tried to do this with their AllCache architecture, and
even marketed two generations of machines based on that system. They
are no longer in business. Efficient communications requires more
hints from the application than you have got at the memory level.
> I can think of bad design decisions that result in needing more than 64k
> threads; what I'd like to see is a legitimate example which doesn't
> involve a bad design decision. :-)
Yup. There are applications where you can imagine a great many
threads of context, but you can always multiplex application threads
onto a smaller number of kernel threads.
Cheers,
Stephen.
-- Stephen Tweedie <sct@dcs.ed.ac.uk> Department of Computer Science, Edinburgh University, Scotland.