[mpich-discuss] MPI_THREAD_FUNNELED

[Pavan Balaji]

On 05/06/2012 11:07 AM, Jed Brown wrote:
> As far as I know, this only causes locking around some potentially
> unsafe system calls. My concern is that we usually don't know whether
> the user is asking for threads until we have processed run-time options,
> which is normally done after calling MPI_Init_thread(). Is there a
> downside to asking for MPI_THREAD_FUNNELED even if only
> MPI_THREAD_SINGLE semantics will be needed?

Dick Treumann or Marc Snir are the right people to answer this question, 
but here's my attempt --

Theoretically, there can be a difference between SINGLE and FUNNELED, 
precisely because of the reason you mentioned above.  But practically, I 
don't see that happening.  Memory allocation calls such as malloc(), for 
which this was meant to make a difference are already thread-safe now.

SERIALIZED is a bit tricky.  Currently, MPI implementations can get away 
with treating it as SINGLE because threading libraries like pthreads do 
a full memory barrier when you synchronize between the threads.  So, the 
updates made to the MPI stack by one thread are visible to the MPI stack 
view of the other threads.  I don't think generic threading libraries 
will stop doing that -- if they do, applications will have so many 
problems that MPI will be the least of their concerns.  But new 
HPC-oriented threading libraries (such as user-level threads) might not. 
  So, SERIALIZED might have some overhead in the future.

  -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji