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!psuvax1!uwm.edu!cs.utexas.edu!utnut!nott!cunews!tina.mrco.carleton.ca!knight
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Multithreading
Message-ID: <knight.784792765@tina.mrco.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
References: <CyyHLD.BIo@world.std.com> <hbakerCyyn4I.8p0@netcom.com> 	<patrick_d_logan.187.000CEA4B@ccm.jf.intel.com> <LGM.94Nov13173410@polaris.ih.att.com>
Date: Mon, 14 Nov 1994 05:59:25 GMT
Lines: 38
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:17953 comp.lang.scheme:11244 comp.lang.lisp:15615

In <LGM.94Nov13173410@polaris.ih.att.com> lgm@polaris.ih.att.com (Lawrence G. Mayka) writes:

>I am quite impressed, if I understand you correctly.  You are saying
>that a major Smalltalk vendor already supports "real" multithreading
>on a popular platform--"real" multithreading in the sense described in
>the original post: the ability to run different threads on multiple
>processors, within the same address space, integrated with the host's
>own multithreading support.  Moreover, other implementations that do
>likewise, on other platforms, are on the way, you say.

No, this is not the case, and I don't know of any released Samlltalks
that can actually do this. Most Smalltalks have their own internal
process model. Thread support usually consists of the ability to run
API calls in a separate thread.

>Naturally, most major commercial Common Lisp implementations--and at
>least one free-of-charge implementation--support "simulated"
>multithreading: the ability to run multiple threads preemptively in a
>single address space on a single processor, but without any host
>integration of the threads.  Preemption might be accomplished via
>alarm(), and nonblocking I/O via select().  Even aside from the
>confinement to a single processor and the inefficiency of managing
>threads without host support, "simulated" multithreading can also be
>marred by system calls that cannot be made nonblocking or which
>otherwise don't fit into a user-level multithreading scheme--e.g.,
>UNIX message queues and semaphores.

If you can run API calls in a separate thread, as IBM can and Digitalk
either can or will be able to soon, then this is not a problem. I
think the overhead is very small. The major disadvantage is the
inability to take advantage of OS facilities for distributing threads
to multiple processors.

-- 
 Alan Knight                | The Object People
 knight@acm.org             | Smalltalk and OO Training and Consulting
 alan_knight@mindlink.bc.ca | 509-885 Meadowlands Dr.
 +1 613 225 8812            | Ottawa, Canada, K2C 3N2
