Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ginosko!uakari.primate.wisc.edu!xanth!mcnc!rti!xyzzy!kan
From: kan@dg-rtp.dg.com (Victor Kan)
Newsgroups: comp.lang.c
Subject: Re: threads for C/C++ under Unix?
Message-ID: <1809@xyzzy.UUCP>
Date: 12 Oct 89 21:09:30 GMT
References: <12298@polya.Stanford.EDU>
Sender: usenet@xyzzy.UUCP
Reply-To: kan@mutley.dg.com ()
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 58

In article <12298@polya.Stanford.EDU> hall@eclipse.stanford.edu (Keith Hall) writes:
>  1.  Does a portable preemptive thread package for Unix, such as
>      described above, exist?

I've know of two systems that might fit the bill.  When I was TAing an
OS course, a grad student working in Columbia's Center for Telecommunications
Research (CTR) wanted to do his concurrent programming assignments using 
some C package that ran on Suns.  I don't know the name of the package, 
but it does exist.  Concurrent C, maybe????  But maybe it's not preemptive.

The other system is Turing Plus (and its ancestor Concurrent Euclid).  
Both come from the University of Toronto's Computer Systems Research
Institute (CSRI).  They are concurrent language systems that can run
under Unix (an unmodified kernel) and both support preemptive, lightweight
threads.  Since both languages are translated into C under Unix, it 
should be possible to link the concurrency simulation kernel (running on
top of the Unix kernel) into other C programs. 

>  2.  Is there a reason such a package cannot be written without
>      kernel modifications?

Nope.

>  3.  If kernel mods are required, why haven't we programmer's
>      demanded that they be done?  Put another way, is the utility
>      of threads not generally recognized?

Threads are recognized by a lot of people.  Unfortunately, most of those
people happen to be in academia and research, rather than commercial
development shops.  It's fine and dandy for researchers at Stanford to
play with lightweight threads in the V system.  But real world 
developers have enough problems debugging multiprocess software systems
that use heavyweight threads (processes).  I know because that's what 
I'm doing now.  Admittedly, many of our local ipc problems wouldn't be 
too bad if we had a single address space to contend with.  Mucking with 
shared memory between processes is a real pain in the butt.

But lightweight threads would make life even tougher.  When I did my
project for a course in parallel architecture and algorithms, I used 
Turing Plus and its lightweight thread features (which I enhanced to 
be parallel).  Conventional debugging, using print statements (with
pseudo-pids for clarification) along with a single thread debugger 
was pretty much useless.  There was simply too much going on at once
to understand what was happening.  Unless somebody develops a real 
concurrent debugger, lightweight threads won't be too useful, outside 
of trivial programs and academic curiosity.

>
>Thank you for your responses, either to this bboard or back to me.
>
>Keith Hall
>hall@eclipse.stanford.edu
>


| Victor Kan               | I speak only for myself.               |  ***
| Data General Corporation | Edito cum Emacs, ergo sum.             | ****
| 62 T.W. Alexander Drive  | Columbia Lions Win, 9 October 1988 for | **** %%%%
| RTP, NC  27709           | a record of 1-44.  Way to go, Lions!   |  *** %%%