Newsgroups: comp.lang.smalltalk,comp.lang.scheme,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!news.kei.com!ub!csn!gw1.att.com!nntpa!nntpa.cb.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: Multithreading
In-Reply-To: patrick_d_logan@ccm.jf.intel.com's message of Tue, 8 Nov 1994 12:54:49
Message-ID: <LGM.94Nov13173410@polaris.ih.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <CyyHLD.BIo@world.std.com> <hbakerCyyn4I.8p0@netcom.com>
	<patrick_d_logan.187.000CEA4B@ccm.jf.intel.com>
Date: Sun, 13 Nov 1994 23:34:10 GMT
Lines: 70
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:17948 comp.lang.scheme:11233 comp.lang.lisp:15611

In article <patrick_d_logan.187.000CEA4B@ccm.jf.intel.com> patrick_d_logan@ccm.jf.intel.com (Patrick D. Logan) writes:

   >In article <CyyHLD.BIo@world.std.com> edwards@world.std.com (Jonathan 
   Edwards) writes:

   >>Is there a Lisp or Smalltalk that does REAL multithreading? 

   Digitalk's Smalltalk/V does real threading for OS/2.

   At some point their Smalltalk/V for Win32 will do real threading for NT & 
   Win95 and will be compatible with the thread classes for OS/2. The current 
   release of their Win32 Smalltalk/V does not support real threads.

   QKS SmalltalkAgents is supposed to do real threading for NT & Win95 when it is 
   released first half '95. They are also supposed to have a Unix (platforms?) 
   product in that time frame. Since their Smalltalk implementation is based upon 
   a port of their own virtual machine which supports threading, the Unix 
   Smalltalk could have threads as well.

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.

As I recall, Top Level's implementation of Common Lisp supported
"real" multithreading.  Unfortunately, Top Level apparently did not
survive, and I don't think any remaining vendor picked up their
technology.  I believe Franz used to offer "real" multithreading on a
particular platform (Sequent?), but I don't know if Franz still
supports that implementation, or ever attempted to port it to more
popular platforms.


   The problem with language vendors implementing their own virtual machines that 
   support threads is that if the native OS does not support threads then it is 
   *possible* that the threads will not behave as you might desire: e.g. I/O on 
   one thread may block all threads, which is undesirable. I do not know if QKS' 
   STA suffers from this or if they have worked around it.


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.


   In general, NT & Win95 have threading as a part of the API, so it would be 
   logical for language vendors to support them.

I'd certainly like to see this, as long as it doesn't compromise other
necessary or highly desirable characteristics of Common Lisp (e.g.,
growable stacks) or, alternatively, if support for the current
"simulated" multithreading is also retained for the sake of its
greater flexibility.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
