From: Mathew Lodge
Subject: Re: Threads (was: C is faster than lisp (lisp vs c++ / Rick Graham...))
Date: 
Message-ID: <334@cinnamon.ferndown.ate.slb.com>
In article <··········@cogsci.ed.ac.uk> Jeff writes:
>In article <··········@disuns2.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira
) writes:
>>In article <··········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writ
es:
>>
>>> Why is that a problem?  Let's take a fairly ordinary Lisp
>>> implementation in which GC is a subroutine that "cons" and some
>>> other operations might call.  Now, if that subroutine is running,
>>> then the parallel C thread isn't, because lw processes don't
>>> provide real parallelism.
>>
>>First, there can be "real parallelism" very easily, given the
>>current "symmetric multiprocessing" workstation trend (not the
>>lisp lw processes, the Unix threads).
>
>Ok.  But I thought that threads / lw processes didn't give you real
>parallelism even then -- that is, within one "heavyweight" process.
>(I.e. you could have real parallelism if > 1 processor, but not
>between lw processes.)

That's not the case. The notion of "process" is significantly changed: a
process is just a container for threads. The scheduler just schedules
threads for execution. An "ordianry" Unix process that does not use threads
is implemented as a container with a single thread running in it -- the
process (and the user) is unaware of this implementation detail.

The scheduler will use the first available processor to run a thread.
Whether the thread to be run comes from the same process container as a
thread already running on another processor is irrelevant: why should the
scheduler care?

Is is this behaviour that makes multi-threaded Unix kernels worthwhile: why
bother with a multi-threded kernel if you can only run one kernel thread at
once?

>But if some Lisp procesure is running, and you don't have real
>parallelism, how can anything in C space be running?

What is "C space"? If you have a single processor system and one thread is
being run by the processor, then all the other threads are waiting.
Pseudo-parallelism is performed by time-slicing. You get real parallelism
when you have 2 or more processors.

Mat

| Mathew Lodge, Software Engineer, | "It's bad enough to have one's life in |
| Schlumberger Technologies (ATE)  |  utter ruin without being serenaded by |
| Ferndown, Dorset, UK, BH21 7PP   |  a moron with all the entertainment    |
| Email: ·····@ferndown.ate.slb.com|  value of a tap-dancing oyster"        |
| Phone: (+44) 202 893535 x404     |  Black Adder, The Cavalier Years       |
From: Jeff Dalton
Subject: Re: Threads (was: C is faster than lisp (lisp vs c++ / Rick Graham...))
Date: 
Message-ID: <CvGMwG.I4F@cogsci.ed.ac.uk>
In article <···@cinnamon.ferndown.ate.slb.com> ·····@ferndown.ate.slb.com (Mathew Lodge) writes:
>The scheduler will use the first available processor to run a thread.
>Whether the thread to be run comes from the same process container as a
>thread already running on another processor is irrelevant: why should the
>scheduler care?

Why should it matter what the scheduler cares about?  Its role is just
to implement whatever semantics we want.

You can of course implement things in the way you describe.  I was
merely under the impression that lw processes did not normally refer
to such a case.

>Is is this behaviour that makes multi-threaded Unix kernels worthwhile: why
>bother with a multi-threded kernel if you can only run one kernel thread at
>once?

Kernels are a rather special case.  It's not pointless to have 
lw processes when only one can run at once.

>>But if some Lisp procesure is running, and you don't have real
>>parallelism, how can anything in C space be running?
>
>What is "C space"?

Ask whoever introduced it.

> If you have a single processor system and one thread is
>being run by the processor, then all the other threads are waiting.
>Pseudo-parallelism is performed by time-slicing. You get real parallelism
>when you have 2 or more processors.

Just so.  So if a Lisp procedure (or the Lisp GC) is running, that's it.

-- jeff