Newsgroups: comp.lang.smalltalk,comp.lang.scheme,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!gatech!bloom-beacon.mit.edu!apollo.hp.com!netnews
From: sommerfeld@apollo.hp.com (Bill Sommerfeld)
Subject: Re: Multithreading
Sender: usenet@apollo.hp.com (Usenet News)
Message-ID: <Cz2EoI.86s@apollo.hp.com>
Date: Thu, 10 Nov 1994 18:43:30 GMT
References: <CyyHLD.BIo@world.std.com> <hbakerCyyn4I.8p0@netcom.com>
Nntp-Posting-Host: snarfblatt.ch.apollo.hp.com
Organization: Hewlett Packard, Chelmsford Site
Lines: 41
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:17863 comp.lang.scheme:11149 comp.lang.lisp:15575

In article <hbakerCyyn4I.8p0@netcom.com>,
Henry G. Baker <hbaker@netcom.com> wrote:
>In article <CyyHLD.BIo@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
>>Is there a Lisp or Smalltalk that does REAL multithreading? Not cooperative 
>>multiprocessing, but real OS-kernel pre-emptive threads. This means threads
>>can run on multiple processors in an SMP, and taking a virtual memory fault
>>in one thread does not block others. How does GC interact with threads?
>>
>>I am afraid I am doomed to C++ unless I can find this. Forgive me.
>
>Excuse me, but what makes you think that C++ 'does REAL
>multithreading'?  The C++ _language_ knows nothing about threads, and
>therefore you have to take 100% of the responsibility yourself for
>managing multiple access to shared variables, classes, etc.

Right, but because C and C++ are low-level languages, it's possible to
do that..  Such things are manageable, albeit difficult, even if you
don't have control over the C or C++ implementation.  Typically, you
need about 100 lines of assembler to manage the context switch, and
some additional architecture-specific code to efficiently handle
mutexes.  There are any number of threads packages for C and C++ out
there which don't require that you change the compiler or run-time
library.

With C++, there are likely to be some minefields; things like
exception handling may not be implemented in a thread-safe manner, but
if you stay away from the minefields, you can get work done.

In contrast, with LISP-type systems, you're facing a much bigger
battle.  All of the threading packages I've seen in freeware Schemes
are built on top of call/cc, so they're inherently uniprocessor.
Indeed, the description of the dynamic-wind extension proposed for
R5RS seems to constrain Scheme implementations to a
single-synchronous-flow-of-control-per-address-space model, which
seems *wrong* to me.

It would be an interesting, umm, exercise to extend a Scheme
implementation to use an OS's threading package.  There are going to
be some big headaches in the vicinity of GC and memory allocation...

					- Bill
