[MUD-Dev] Two threads forced to one CPU? (was: Collecting ideas for a MUD server...)

[J C Lawrence]

On Thu, 23 Dec 1999 01:40:44 -0800 (PST) 
Wesley W Terpstra <terpstra at iota.dhs.org> wrote:

> You're saying if I spawn two threads and having both work nonstop
> the OS won't put them on different CPUs?

Not necessarily.  Further, very few OSes support runtime thread
migration (IRIX is one of the few FWIW).  

What does this mean?  

Scenario:

  If you have say a 2-way box with a single process hogging one CPU,
and the second CPU mostly free, new threads are most likely to be
assigned to the second CPU.  This is reasonable.  Now let's say that
the hoggy process dies, leaving the second CPU hogged with threads
and the first entirely idle.

  Under most current OSes nothing changes.  All the threads continue
execution on the CPU they were originally assigned and the first CPU
remains idle.  Future thread and process starts will likely be
assigned to the firt CPU, but if there are none it will remain idle.
Some OSes, and they are very few, will dynamically migrate threads
between CPUs (and even between nodes in a cluster in some cases (cf
IRIX CC:NUMA)) at runtime to best use available resources.  

> I thought this was the whole point to multi-threading?  

There are a great many points to MT.  The base concept is getting
multiple process counters in a single shared code and data segment.
Once you get past there into the realms of justification you can be
talking about almost anything.

That all said, probably the most common reason used for MT is the
comment Rahul (?) made about blocking.

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev