🚀 go-pugleaf

In article <1991May12.230130.8199@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes:

| This would involve mutex's to lock on and a conditional
| variable for the master thread to wait on, to discover which slave
| thread is (or is about to) exit.  My objection to doing it this way
| is that this seems like the kind of extra management work that a package
| like C threads should really have implemented in the first place.

Actually, if I were to do it over again, I would think seriously about
not even including the single-thread join as part of the C Threads
interface.  It's entirely implementable in terms of the other
mechanisms provided (mutual exclusion and synchronization, plus
per-thread data).

There's nothing magical that the C Threads implementation can do to
implement multi-thread join (or multi-condition wait, another
often-requested feature) any better than the application can.  So why
build in one particular mechanism?  Tomorrow there will be another
application that needs something similar, but not quite the same.

Instead, the goal is to provide a low-level, efficient, but
machine-independent set of primitives for shared-memory parallel
programming, and allow higher-level packages for various idioms
(futures, barrier synchronization, etc.) to be built on top.

	Professor Eric C. Cooper
	CMU School of Computer Science
	5000 Forbes Avenue
	Pittsburgh, Pennsylvania  15213-3890

	Internet: ecc@cs.cmu.edu
	   Phone: +1 412 268 3734
	     FAX: +1 412 681 5739