Re: Why Events Are A Bad Idea (for High-concurrency Servers)

["P.H.Welch" <P.H.Welch@xxxxxxxxxx>]

Hi Adelaide,

> I wonder if you could help me to tell clearly multitasking from
> multithreading.

Different people use the same words to mean different things.  Mostly,
I use neither of those terms - and talk about multiprocessing, which
covers both software and hardware concurrency.

However, the traditional view is that "multitasking" is what operating
systems do - separate jobs living in their own (virtual) memory space
and so unable to conflict via memory with each other.  The OS schedules
them to its processor or processors, promising to progress them fairly
or according to some priority scheme.  This scheduling tends to be
heavy (i.e. time consuming - hundreds of microseconds), since there
is lots of state to save and restore.

"Multithreading" is the scheduling of multiple threads of control, each
operating in the same memory space and working on a common problem.
They do conflict over memory and so locking mechanisms of various kinds
(e.g. semaphores, monitors) are provided to let the user protect them
from each other - very hard to reason about though.  Thread scheduling
is sometimes called "lightweight" - one to tens of microseconds - but
they're only lightweight compared to "multitasking".

I work with (CSP) processes - each process living in its own memory
space (so no memory conflicts and no locks needed) and communicating
over synchronising channels.  Scheduling overheads are in the tens of
nanoseconds (yes, nanoseconds).  The ideas apply to fine-grained
process networks solving a common problem (e.g. modelling/controlling
a hundred million nanobots) and up though all levels of scale (e.g.
to a web-distributed eCommerce system).  Whatever "multitasking" or
"multithreading" are, they don't provide a conceptual model that
addresses such a range of application.

Hope that helps!

Peter.