[MPICH] MPICH2 Thread-safety

Rajeev Thakur thakur at mcs.anl.gov
Fri Jun 9 08:54:54 CDT 2006


Sylvain,
        A lot of things are happening thread-safety-wise in MPICH2. 1.0.4
will have much better support. Nonetheless, the paragraph you quote will
work in 1.0.3 as well because the lock is released somewhere inside the
progress engine before a receive blocks. (It's not obvious from looking at
the code for MPI_Recv.)  What exactly doesn't work for you? We have fixed a
couple of bugs that were found.

Another fix that is coming is that you won't need to build MPICH2 separately
to get a thread safe version. Support for thread safety will be there by
default and will be enabled when the user selects it with MPI_Init_thread.
If the user doesn't call MPI_Init_thread, the code will not use any thread
locks, so there is no penalty.

Rajeev

  

> -----Original Message-----
> From: owner-mpich-discuss at mcs.anl.gov 
> [mailto:owner-mpich-discuss at mcs.anl.gov] On Behalf Of Sylvain Jeaugey
> Sent: Friday, June 09, 2006 7:04 AM
> To: mpich-discuss at mcs.anl.gov
> Subject: [MPICH] MPICH2 Thread-safety
> 
> Hi all,
> 
> After some tries, it looks like MPICH2 is still a little far 
> from being 
> thread-safe.
> 
> Nothing seems to be currently done in this direction, so I'm 
> posting here 
> to know what I could do to improve this.
> 
> The only thread policy is "global_mutex", which -in my view- 
> contradicts 
> Section 8.7.1 of the standard :
> 
> "Example Process 0 consists of two threads. The first thread 
> executes a 
> blocking send call MPI_Send(buff1, count, type, 0, 0, comm), 
> whereas the 
> second thread executes a blocking receive call MPI_Recv(buff2, count, 
> type, 0, 0, comm, &status). I.e., the first thread sends a 
> message that is 
> received by the second thread. This communication should 
> always succeed."
> 
> There is a lot of code for "thread-safety". Still, I can't 
> get something 
> working.
> Is there a chance that things will be better in 1.0.4 ? Where 
> should I 
> begin if I want to improve things (and not destroy what's already be 
> done) ?
> 
> Thanks in advance,
> 
> Sylvain
> 
> 




More information about the mpich-discuss mailing list