threads for C/C++ under Unix?
Victor Kan
kan at dg-rtp.dg.com
Fri Oct 13 07:09:30 AEST 1989
In article <12298 at polya.Stanford.EDU> hall at 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 at 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! | *** %%%
More information about the Comp.lang.c
mailing list