Newsgroups: comp.parallel From: zhou@isis.epm.ornl.gov () Subject: Summary on Threads Organization: Oak Ridge National Lab Date: Tue, 7 Jun 1994 12:43:19 GMT -------- From: Matt Haines I'm not sure if you're interested in thread uses or thread packages, but I'll assume that you may be interested in both. We're working on a system called Chant, which integrates lightweight threads with distributed memory communication, both point-to-point and remote service request. Chant extends the POSIX pthreads standard by introducing a new thread object, called a "chanter", which is capable of remote communication and remote thread operations. Chant sits atop pthreads and a communication library (such as MPI, p4, ...), and provides the necessary "glue" for an efficient implementation. For more information on the Chant project, take a look at "http://www.icase.edu/~haines/html/chant.html", or contact me. Matt *** (haines@icase.edu) *** http://www.icase.edu/~haines/haines.html -------- From: "Vernard C. Martin" try anonymous ftp to ftp.cc.gatech.edu in pub/coc/tech_reports/1993/GIT-CC-93-37.ps.Z -- Vernard Martin (vernard@cc.gatech.edu) Ga Tech College of Computing Student at Large, High Performance Parallel Computation and Experimentation Lab Atlanta, GA 30332-0280 Phone (404) 853-9390 "Live large and prosper." - MC Spock --------- From: Sylvain_Boivin@uqac.uquebec.ca (Sylvain Boivin) Hi, this is an excellent idea. Here is what I use: - POSIX 1003.4a Threads standard Draft 6. - SunOS 5.2 Guide to Multi-Thread programming. - F. Muller. "A Library Implementation of POSIX Threads under UNIX", USENIX, Jan. 1993. The later can be found (with some others and with a good threads library) on ftp.cs.fsu.edu in /pub/PART. /-----------------------------------------\ Find 1 bug (=> true for n=1) / Sylvain Boivin, sboivin@uqac.uquebec.ca \ Let suppose there are n bugs \ Universite du Quebec a Chicoutimi, CANADA / Find another 1 (=> true for n+1) \-----------------------------------------/ Theorem: "There is always a bug" -------- From: Jocelyne Farhat Here are few references for you to begin with : [POW 91] M.L. Powell et al. "SunOS Multi-thread Architecture." USENIX Winter 1991, Dallas, Texas. [BER 88] B. Bershad et al. "PRESTO: A System for Object-oriented Parallel Programming". Software Practice and Experience, Vol 18(8), pp.713-732, August 1988. [AND 91] T.E. Anderson et al. "Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism". Proc 13th symp on O.S. Principles, ACM, pp. 95-109, 1991. [FAU 90] J.E.Faust and H.M.Levy "The Performance of an Object-Oriented Threads Package". Proceedings on Object-Oriented Programming: Systems, Languages, and Applications, Canada, Octobre 1990 [AND 89] T.E.Anderson et al. "The Performance and Implications of Thread Management Alternatives for Shared-Memory Multiprocessors". IEEE Tr on Computers, Vol. 38, No. 12, pp 1631-1644, December 1989 [MUE 93] F.Mueller "A Library Implementation of POSIX Threads Under UNIX Winter" USENIX, January 25-29 1993, San Diego,CA. [BER 92] B.N. Bershad, R.P. Draves and A. Forin. "Using Microbenchmarks to Evaluate System Performance". Proceedings of the Third Workshop on Workstation Operating Systems (WWOS-3), April 1992. [DRA 91] R.P Draves et al. "Using Continuations to Implement Thread. Management and Communication in O.S.", Proc 13th symp on O.S. Principles, ACM, P122-136,1991 [INO 91] S.Inohara and K.Kato and T.Masuda, "Thread Facility Based on User/Kernel Cooperation in the {XERO} Operating System" in Proceedings of the fifteenth IEEE International Computer Systems and Applications Conference (IEEE Computer Society), pages 398--405, September1991, [INO 93] S Inohara and K.Kato and T.Masuda "'Unstable Threads' Kernel Interface for Minimizing the Overhead of Thread Switching" in Proceedings of the 7th IEEE International Parallel Processing Symposium, pp 149--155, April 1 ******************************************************************** Jocelyne Farhat farhat@inf.enst.fr Departement Informatique Telecom Paris tel : (33-1) 45 81 79 95 46, rue Barrault fax : (33-1) 45 81 31 19 75634 Paris 13 (33-1) 45 81 81 20 FRANCE ******************************************************************** --------- From: A.D.Ben-Dyke@computer-science.birmingham.ac.uk @TechReport{Active:Messages, author = {David E. Culler and Seth Copen Goldstein and Klaus Erik Schauser and von Eicken, Thorsten }, title = {Active Messages: A Mechanism for Intgerated Communication and Computation}, institution = {University of California, Berkeley}, year = {1992}, number = {UCB/CSD 92/675}, month = {March}, email = {tve, culler, sethg, schauser@cs.berkeley.edu}, ftp = {ftp.cs.berkeley.edu:/ucb/TAM/isca92.ps}, annote = {Starting with the premise that current MPP designers tend to optimise along specific dimensions rather than towards a balance (considering that most I/O networks try and deliver high volume comms, but to avoid peak processor performance 90% of the time must be spent in computation => expensive network is mostly idle!) To achieve a blance, startup cost must be low, and a means to overlap comms and computation must be provided: hence the active message, which is simply a message containing in its header the adress of a user-level handler which is executed on message arrival. The role of the handler is to extract the message as quickly as possible and to integrate it into the current computation. Not suprisingly, such handlers must not be allowed to block. One advatange is that no temporary bufers are required, as the program code will have pre-allocated space for the message, however care must be taken to avoid deadlocking. The paper then shows how implementations of this low-level construct runs very efficiently on the nCube and CM5 (orders of magnitude faster). Next, the Split-C programming model is described, which uses a put and get op to copy data to and from processors. By requesting data as earlier as possible, and only blocking on the value when it's actually needed the computation/comms overlay is very high. Utilisation measurements for a range of data distributions (columns per processor) shows that while processor and network utilisation fluctuate the joint utilisation is relatively steady. Moving on the paper describes the threaded abstract machine for compilers, and speculates on the hardware support that could improve efficiency of such a model. Active messages are compared with the Monsoon and J-machine tokens, and found to be different}, got = {yes}, } @InProceedings{DepAnal:Threads, author = {Kenneth R. Traub and David E. Culler and Klaus E. Schauser}, title = {Global Analysis for Partitionning Non-Strict Programs into Sequential Threads}, institution = {Motorola Cambridge Research Center and University of California, Berkeley}, booktitle = {Lisp and Functional Programming}, year = {1992}, pages = {324--334}, email = {kt@mcrc.mot.com, culler, schauser@cs.berkeley.edu}, ftp = {ftp.cs.berkeley.edu:/ucb/TAM/lfp92.ps}, annote = {Discusses how threads can be extracted from the Id base language (a non-strict but eager language) to ensure the largest thread size possible. Note: a thread is defined as an ordering which 1. is defined for all possible invocations 2. possible to complete the execution without any pauses. Data flow graphs using certain and indirect dependence labels, with send/receive annotations, is used. Two partitionning methods, demand and dependence analysis are defined, along with subpartitionning (removes blocks linked by indirect dependences from a thread). Using these building blocks a global algorithm is discussed and the special cases of conditionals discussed. Compares favourably to strictness anal for LAZY languages (need to remove dependence analysis) as it yields larger threads, but recursion isn't as well defined under this scheme.}, got = {yes}, } @TechReport{Split:C, author = {David E. Culler and Andrea Dusseau and Seth Copen Goldstein and Arvind Krishnamurthy and Steven Lumetta and von Eiken, Thorsten and Katherine Yelick}, title = {Parallel Programming in {Split-C}}, institution = {University of California, Berkeley}, year = {1993}, email = {Split-C@boing.cs.berekeley.edu}, ftp = {ftp.cs.berkeley.edu:/ucb/split-c/sc93.ps.Z}, annote = {Based loosely on the SPMD model, with global address space with a clear concept of locality, the languages allows a mixture of parallel paradigms (message passing, shared memory and data parallelism). The extensions to standard C include global pointers (reference objects on remote processors - maths such as ++ works correctly), split-phase assignment (:= allows comms/processing to be pipelined), signalling store (remote update with notification), bulk transfer and spread arrays. Using a program for modelling electromag waves as an example, the power of the models is used to show how simple optimisations improve effiicency by a factor of 4-5 on a 64 processor CM-5 (using ghost nodes, split phase comms and signalled stores).}, got = {yes}, } ------- From: kaushik@cc.gatech.edu (Kaushik Ghosh) "Experimentation with configurable, lightweight threads on a KSR multiprocessor" It is available as a tech-report (as are all the papers written by our group) from ftp.cc.gatech.edu. Browse around to see our other work... Kaushik. ------- Enjoy! Honbo ---- Honbo Zhou (Ph. D.), (615) 481-8354 (H), 576-6129 (O) Engineerin, Physics, and Mathematics Division ---- PVM Oak Ridge National Laboratory, Oak Ridge, TN 37831-6367 ------- Newsgroups: comp.parallel.pvm From: kees@cwi.nl (Kees Blom) Subject: Re: PVM and thread library Summary: DTh - Distributed Threads Organization: CWI, Amsterdam Date: Mon, 11 Jul 1994 13:11:49 GMT Message-ID: Distributed Threads ! ------------------- We have developed the `DTh' library, which stands for: Distributed Threads. It is a collection of C functions to support distributed and parallel applications running in a heterogeneous computing environment. It supports tasks, threads and monitors, and communications between them. For more information, including availability, please contact the developer: Farhad Arbab, email: farhad@cwi.nl, phone: +31 20 5924056. Kees Blom (email: kees@cwi.nl, phone: +31 20 5924053).