phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/13/91)
This question applies to the C threads library which is part of Mach. I decided to ask here since those familiar with this might be here in greater concentration. Suppose I have a master thread that forks off several slave threads. It is indeterminate when the slave threads will finish, including the order in which they will finish. How can the master thread "join" or otherwise wait for the conclusion of the first of the slave threads to finish? It seems to me that the only way to do this, given that the "join" function only addresses one thread, is to have the threads manage some shared queue upon which elements are placed to identify the ending thread. 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. Comments? Maybe a fuller description of the goals of the C threads package that is part of Mach will make this clearer. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
ecc@CS.CMU.EDU (Eric Cooper) (05/15/91)
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