Newsgroups: comp.parallel.pvm
From: zhou@isis.epm.ornl.gov (Honbo Zhou)
Subject: Re: Signals and Threads and PVM (long and somewhat rambling)
Organization: Oak Ridge National Lab, Oak Ridge, TN
Date: 21 Feb 1995 19:51:07 GMT
Message-ID: <3idg7b$gj1@stc06.CTD.ORNL.GOV>

Bob Manchek (manchek@thud.CS.UTK.EDU) wrote:

: Since there has been a lot of talk about signals...

: I'm interested in making libpvm thread- and signal-safe, but there are
: a number of decisions to be made and implemetation issues, not the
: least of which is keeping the resulting code portable.

: There are two main issues that have to be dealt with to make PVM
: multi-thread safe:  Global state and reentrancy.  Global state includes
: simple things like the last error code and more complex things like the
: PVM message buffer heap.  Reentrancy means being able to call a
: function again while you're already in it.

: The point is, using signals is ugly can of worms to open up, and I don't
: think it buys us much.

: So, that brings us to threads.  Instead of interrupt message handler
: functions, what about a more general scheme such as interrupt handler
: threads?  On receiving an interrupt message, libpvm would thork a new
: thread to handle it.  The message-marshalling thread in libpvm would
: already exist (from the first call to install an interrupt handler
: or before that) to create it.

: We could remove global state from libpvm, and build a thread
: dispatching mechanism.  But we have to have a thread package portable
: enough (or make it removeable enough) to function on any of the
: machines on which PVM can run.  I hope we could do this by making a
: thin glue layer that would interface between PVM and any thread
: package, giving us access to the few lock, thread-create, etc.
: primitives that we need.  Last I heard, Honbo Zhou at ORNL was trying
: to figure out how to do this.

: Then, there are other questions such as:  What should the semantics of
: the thread dispatcher be?  Do you allocate a single thread to handle a
: message class (another doesn't start until the previous one terminates)
: or or do you start as many as you receive messages.  I haven't thought
: much about this yet.

I can not agree more with Bob... It's certainly a good idea to make libpvm 
mt-safe. It seems to me that related new developments such as Acitive 
Messages etc. and efficient use of emerging SMP machines require PVM to have 
thread abilities. The TPVM package doesn't seem to have much performance
gain mostly (to me) because it's a layer on top of the normal PVM and 
implemented in a non-intrusive way. It would be nice if PVM could have 
built-in threads. For example, to achieve better performance, pvmd-local 
tasks communication could have been based on shared memory facilities available
on almost all unix platforms, but the process based implementation could not
take advantage of the shared memory due to slow context switching. The use
of threads may change the situation.

There is a small thread package called REX (available from 
gummo.doc.ic.ac.uk:/rex/lwp.tar.gz), it provides most of the primitives
Bob talked about. TPVM is based on it. The problem is that this package
has been only shown to work on SUN4 machines (not on Solaris), but it
has the potential of being easily (easier than to port the fat pthread 
packages) ported to other platforms. I have been trying to port it to
RS6K, HPPA, ALPHA, etc. platforms but only got it work on ALPHA due to
lack of architecture and assembly language manuals...

2c

Honbo

--
               Honbo Zhou (Ph. B)
 Mathematical Sciences Section, Bldg 6012, MS 6367 
Oak Ridge National Laboratory, Oak Ridge, TN 37831
          http://www.epm.ornl.gov/~zhou

