lkml.org 
[lkml]   [1996]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: proc fs and shared pids
Hi,

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.



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.105 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site