pcb@usl.usl.edu (Peter C. Bahrs) (04/19/89)
We just finished an object oriented (C++) message passing programming environment running under Threads. The old version was developed with parallel.h, this one with threads.h. I still have some questions though... Is parallel.h et.al. being phased out??? I noticed that including the two .h files produces a conflict in the Semaphore definition. Or is just the task stuff being replace with the threads stuff? I still am never sure what to set for stack size and datasize in threadgo and threadcreate. I am using the constants in the threads.h file but.... When a threadgo is called, does this create a high priority process that will not get bumped by the process scheduler? Also, does this thread scheduler (the h.pr. process) schedule all thread create objects. Thread go takes N as the number of processors to use. Will jobs remain on the initial processor that they are scheduled to? /*------------Thanks in advance...---------------------------------------+ | Peter C. Bahrs UUCP ... !uunet!dalsqnt!usl!pcb | | The USL-NASA Project ... !cs.utexas.edu!usl!pcb | | Center For Advanced Computer Studies INET pcb@usl.usl.edu | | University of Southwestern Louisiana | | Lafayette, LA 70504 | +-----------------------------------------------------------------------*/
jb@CS.BROWN.EDU (04/25/89)
I don't know what Encore's plans are in terms of parallel programming environments. Threads is supposed to be self contained. I don't think it would interact well with the tasking package. I've never figured out what sizes should be used for stacks and data. Stacks must be made large enough to handle all of the call frames that might be active at once. (Watch recursive routines!) The biggest problem is arrays placed on the stack can get large fairly quickly. Threads may detect the stack overflow for you, but it may not. A lot of damage could be done before the overflow is detected. > When a threadgo is called, does this create a high priority process that > will not get bumped by the process scheduler? Also, does this thread > scheduler (the h.pr. process) schedule all thread create objects. Thread > go takes N as the number of processors to use. Will jobs remain on the > initial processor that they are scheduled to? Threadgo simply forks the required number of processes (one per processor). None of these have any special priorities as far as the underlying OS is concerned. There is no one process designated as the scheduler. When a thread gets suspended, the processor on which it is running, simply examines the run queue and grabs the highest priority thread. A threadcreate is similarly executed on whichever processor the calling thread is using. The only process that is special is one dedicated to I/O. The reason for this is that there is no good way to share open files between all of the processes. One possible solution to this problem was to require all files be opened before threadgo was called. This seems just too restrictive though. Encore had not implemented the passing of file descriptors from 4.2BSD. (That was broken there anyway and not fixed until 4.3 came out.) Even if this was used, there would still be problems with making sure that all processes had the same files open at the same descriptors. I'm not exactly sure what you mean by your last question, but I'll give a shot at answering it. The processes (which provide the illusion of multiple processors being used) are all normal processes will be scheduled like any other process on the system. The threads bounce around between these processes. In other words, not much remains in one place unless the numbers are small. (i.e. fewer threads than processors being used, or fewer processes than processors) Jim