Importance: Normal
Subject: Re: Are attribute copy functions synchronized?
To: William Gropp <gropp@XXXXXXXXXXX>
Cc: mpi-core@XXXXXXXXXXX
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
From: "Richard Treumann" <treumann@XXXXXXXXXX>
Date: Tue, 9 Jan 2001 15:39:40 -0500
X-MIMETrack: Serialize by Router on D01ML077/01/M/IBM(Release 5.0.5 |October 12, 2000) at
 01/09/2001 03:37:21 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


Bill - My position is:

It is erroneous for an MPI implementation to ensure that only one thread at
a time invokes an attribute copy or delete function.  In fact, it is
erroneous for an MPI implementation to hold any lock while a user written
callback function is executing.   (user written reduction functions should
probably be exempt from this no-lock rule)

The MPI standard makes it clear that an MPI call blocked on some thread
must not prevent using MPI on other threads.  Since the user has control
inside the copy or delete function, MPI cannot guarantee the user function
will not block.  Though the case of implicit free of MPI_COMM_SELF at
MPI_FINALIZE is the only case I can think of where an attribute delete
function might be strongly tempted to do MPI communication, the standard
does not prohibit communication in attribute copy or delete functions.

The right model for these functions is to promise the user that MPI will
hold NO lock across a callback and if the user wants to RMW data shared
among threads it is his job to provide a mutex and use it.  This is no
different from any other application code which is designed to run
multi-threaded. Asking the author of thread safe code that uses MPI to do
the right thing in a callback should not be considered a burden .

           Dick

Dick Treumann                RS/6000 SP Development
IBM Poughkeepsie Unix Development Lab
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363


William Gropp <gropp@XXXXXXXXXXX>@mpi-forum.org on 01/09/2001 02:35:50 PM
Sent by:  owner-mpi-core@mpi-forum.org


To:   mpi-core@XXXXXXXXXXX
cc:
Subject:  Are attribute copy functions synchronized?



Consider the following case:  two threads belonging to the same process
both execute MPI_COMM_DUP on different communicators at the same time.  In
addition, both of these communicators have an attribute for a particular
keyval whose copy function looks something like this:

int attr_copy( MPI_Comm oldcomm, int keyval, void *extra_state, void
*attribute_val_in, void *attribute_val_out, int *flag )
{
     int *tag_p = (int *)extra_state;
     int *aval_p;

     aval_p = (int *)malloc( sizeof(int) ); if (!aval_p)
MPI_Abort(MPI_COMM_WORLD,0);
     *aval_p = *tag_p;
     *tag_p  = *tag_p + 1;
     *(void **)attribute_val_out = aval_p;
     *flag = 1;
     return MPI_SUCCESS;
}

This attribute is intended to provide an integer sequence number to each
communicator, based on a single, global value maintained in the keyval's
extra_state.  In the multithreaded case, it is possible for both threads to
read the same value from *tag_p.

Is this a user error?  Should a multithreaded MPI ensure that only one
thread at a time invokes an attribute copy (or delete) function?

 From a user's perspective, I'd answer yes to both - it is a user error,
but I'd like the MPI implementation to handle this for me.  A related
question is: Is it erroneous for an MPI implementation to ensure that only
one thread at a time invokes an attribute copy or delete function?

Bill