subramon@iris.ucdavis.edu (Ramesh Subramonian) (04/14/89)
>This is a request for information and references to information >on threads (a.k.a. lightweight processes). I am interested in >the topic in general and actual implementations. My own experience with threads, as implemented on the Encore MultiMax, (called Encore Parallel Threads) has been a satisfying one in terms of ease of programming. However, I still find the overhead of maintaining the THREADS library extremely high when one is looking for fine-grain parallelism. Possibly this is because I am not using them the way they were menat to be used. Doeppner, the creator of this particular version of THREADS, would be a better guide in this regard. The manual does indicate that one might use micro-threads for greater efficiency when one is not using all the features that Threads provides. However, I have not found any significant improvement on using it. I include two references on Threads and a brief extract from both, which ought to cast light on what threads are all about. --------------------------------------------------------------- Threads: A System for the Support of Concurrent Programming Doeppner, Thomas W. Jr. Department of Computer Science, Brown University, Providence, RI 02912 June 16, 1987. Technical Report CS-87-11 "The Threads system supports the concept of a thread of control (or thread ), which is an independent unit of execution, capable of concurrent execution with other threads. The notion of cheap concurrency is often known as lightweight processes." "In its purest form, a thread represents as little as possible: it is an abstraction of only the agent executing instructions; it is not an abstraction of either instructions or data. The execution of a thread causes local variables and a runtime stack to be allocated, but these are considered not a part of the thread itself but rather a part of the program being executed." "Threads are light-weight. For a highly concurrent style of programming to be useful, threads must be very inexpensive, i.e. the overhead required for creating, synchronizing and scheduling threads must be very low. A typical operating system process is expensive o creat and expensive to synchronize. This is because they usually entail a separate address space and other protection boundaries which are time-consuming to set up. Further, they are managed by the operating system kernel; requests to perform operations such as synchronization must be passed to the kernel over a user-kernel boundary that is typically fairly easy to cross. For example, in Berkeley Unix running on a MicroVAX2, the overhead for a system call is 200 microseconds." "Synchronization and scheduling are in fact separate concepts and should be treated separately. One can build synchronization constructs which determine when it is permissible for a thread to execute, independently of schedulers, which determine which threads to execute from a set of threads for which execution is permissible." A Threads Tutorial Doeppner, Thomas W. Jr. Department of Computer Science, Brown University, Providence, RI 02912 March 30, 1987. Technical Report CS-87-06 "Threads present to the programmer the view that a number of concurrent threads of control are executing in a single shared address space and share a common view of which files are open. Thus threads may communicate very efficiently through this shared memory and all threads may participate in I/O on any file."