Newsgroups: comp.parallel.pvm
From: ajf2j@uvacs.cs.Virginia.EDU (Adam J Ferrari)
Subject: Re: Is PVM Thread Safe?
Organization: University of Virginia Computer Science Department
Date: Fri, 21 Jul 1995 21:57:53 GMT
Message-ID: <DC36CH.K15@murdoch.acc.Virginia.EDU>

In article <3ufa2g$am0@stc06.ctd.ornl.gov>,
zhou@isis.epm.ornl.gov (Honbo Zhou) writes:
> Tony Skjellum (tony@aurora.cs.msstate.edu) wrote:
> : Do either of these solutions conserve legacy codes?  TPVM seems like
> 
> In both TPVM and LPVM, API have somewhat been changed. In LPVM, some
> additional parameters have to be introduced to make PVM thread safe. 
> In TPVM, you have to do explicit export of threads' entry points, etc... 

This is correct. TPVM requires that thread entry points be explicitly
exported by PVM tasks wanting to use TPVM services. That said, the TPVM
programming interface was specifically designed to make porting 
legacy PVM codes easy and automatable. I've had good luck porting
a number of native PVM applications.

> 
> : it might, because thread-oriented calls have a new call, whereas
> : PVM mainline version will have to have a new argument in almost all
> : calls [at least those that refer to a message buffer].  Even with
> : calls that refer to a message buffer having a message-buffer ID,
> : will PVM be thread-safe once the new contexts, static groups,
> : and other feature are added, as discussed at the PVM UG meeting?
> 
> The bottom line is: calls such as pvm_send()/pvm_recv() in the
> current version of PVM is NOT REENTRANT. In LPVM, those calls are
> made reentrant and thread/signal safe. In TPVM, those call are not
> made reentrant. For example, tpvm_send() in TPVM calls pvm_send() to
> do real message passing, since pvm_send() is not reentrant, mutex
> lock has been used in TPVM to make sure there is only one "current"
> pvm_send() running, so even if you have multipe threads running, 
> there can only be one thread doing message passing (this is my 
> understanding, correct me if I am wrong) at a given time. 

Your statement that tpvm_send() uses pvm_send() in mutual exclusion is
correct, but but this design does not imply that only one thread can be
involved in message passing at a time - sends inside an address space
don't ever need to touch pvm_send(). Furthermore, mutually exclusive usage
of pvm_send() doesn't cause a hot spot in the kinds of applications for
which TPVM is intended. The typical mode of TPVM usage involves
threads cooperating across PVM task boundaries using the pvm library for
communication. The number of threads wishing to send a message across
address spaces at any given instant in time is typically small.
While a thread is busy performing such a send, other threads may
make use of the processor time (although sends are not typically the
bottleneck). Similarly, blocking TPVM receives are expected to be
overlapped with useful computation - this is where much of the power
of the TPVM programming model lies.

I think the goals of TPVM and LPVM are different. Making a thread-safe
version of the PVM library code was simply *not* the goal of the TPVM design.
When one considers the difficulty of programming parallel applications
in both the distributed and shared memory paradigms, it seems like a 
dangerous idea to try to support the arbitrary combination of these
programming models (i.e. now, when writing a pvm application, one 
not only has to worry about sends, receives, deadlock, etc. - one also 
has to worry about explicitly synchronizing threads! - the mixture
seems to exponentially complicate the already difficult process 
of writing parallel codes).

Some of the motivations behind TPVM are:

        - To capture lost performance due to overspecification of
          the synchronization constraints of applications. While
          strategies such as send-ahead and explicit use of non-blocking
          communications primitives can also achieve this goal, these
          schemes require considerably more effort on the part of the
          programmer, and are often difficult to integrate into
          existing applications.
        - To take advantage of the small scale multiprocessors which
          have become increasingly available resources in environments
          were PVM is typically used.
        - To facilitate the implementation of support for alternative
          programming models such as active messages and remote memory
          copy. Such schemes can be difficult to implement in a traditional
          process-oriented environment.

In general, the goal of TPVM is to make intelligent use of lightweight
processes in distributed computing environments.
Some of the design goals behind TPVM are to:

        - Retain the well-known PVM programming model as much as possible
          (e.g. to support easy porting of legacy applications).
        - Realize tasks as logically address-space disjoint threads.
          (lightweight processes as defined by underlying thread libraries).
        - Transparently take advantage of fast communication via shared
          memory when possible, and failing that, take care of message
          delivery between address spaces using PVM.
        - Keep the system highly portable. That is,
                - It should not require changes to the native PVM system.
                - It should encapsulate the usage of thread services behind
                  a well defined interface which makes as few assumptions
                  about the underlying thread system as possible. For example,
                  TPVM has been ported to a preemptive, kernel supported
                  thread system, as well as a non-preemptive, user-space
                  thread system.
        - Support heterogeneity. TPVM implementations over different thread
          systems are completely interoperable.
> 
> It would be a nice approach to take advantage of the entry point 
> export feature of TPVM and LPVM's effort to make PVM reentrant 
> (thread and signal safe).

I hope this clears up some of our motivations for design choices
in TPVM. While there are clearly uses for a thread and signal safe
version of the PVM library (based on the traffic in comp.parallel.pvm
on the subject), that wasn't the problem we were trying to solve with 
TPVM.

-Adam 

 
---
Adam J. Ferrari
ferrari@virginia.edu
http://www.cs.virginia.edu/~ajf2j/

