The original idea to have Intelesque HSEND/HRECV in MPI still seems like a
good idea (even if we must limit what handlers can do because we do not
assume threads). This was the existing practice, we understood the usefulness
of these calls, and we understood that there is more that can be done on a
system that has threads (eg, application uses regular MPI plus threads to do
special functionality). Orthogonal functionality: support for receive
and call, and support for threaded MPI implementations, seems appropriate.
Also, all potential RT implementations will want handlers, not all systems
that will run RT have threads. The realtime chapter will reflect the need for
handlers, but it certainly does not want to depend on threads...
On Fri, 21 Jun 1996, Steve Huss-Lederman wrote:
> Date: Fri, 21 Jun 1996 11:12:10 -0500
> From: Steve Huss-Lederman <firstname.lastname@example.org>
> To: email@example.com, firstname.lastname@example.org
> Subject: question on threads proposal
> I am thinking about Marc's recent threads chapter. Before we had the
> ability to lock and unlock handlers. Now p. 4 line 25-6 says one
> should use mutual exclusion with thread synchronization. This seems
> to imply that users who never use threads but want handlers need to
> learn about mutex in their system. Also, this will not be portable.
> Going even farther, what about systems that don't support threads but
> do support handlers. How is mutual exclusion done (system
> I was wondering if we could extend the MUTEX in section 0.1.4 to do
> this. If one gives MPI_COMM_SELF as the communicator then the mutex
> is on the threads within that process. Does this make sense?
Anthony Skjellum, PhD, Asst. Professor of Computer Science;
Mississippi State University, Department of Computer Science & NSF ERC
Butler, Rm 300, PO Box 9637, Corner of Perry&Barr, Mississippi State,MS 39762
(601)325-8435 FAX: (601)325-8997; http://www.erc.msstate.edu/~tony; Quote:
"What a rain of ashes falls on him that sees the new and cannot leave the
old."-Shakespeare ; e-mail: email@example.com; Try MPI!