[Mpi3-hybridpm] Fwd: Threading homeworking / next telecon

[Rajeev Thakur]

A reminder that this telecon is scheduled for tomorrow at noon Eastern. What is the telecon number?

Rajeev


Begin forwarded message:

> From: Rajeev Thakur <thakur at mcs.anl.gov>
> Date: March 14, 2013 4:45:50 PM CDT
> To: mpi3-hybridpm at lists.mpi-forum.org
> Subject: Re: [Mpi3-hybridpm] Threading homeworking / next telecon
> 
> The analysis of thread safety needs of MPI routines that Bill mentioned on Wed is available here: http://wiki.mpich.org/mpich/index.php/Thread_Safety . It is referenced in this paper, www.mcs.anl.gov/~thakur/papers/threads-parco.pdf.
> 
> Rajeev
> 
> On Mar 14, 2013, at 3:00 PM, Barrett, Brian W wrote:
> 
>> Hi all -
>> 
>> As a reminder, there's a hybrid telecon on Monday, March 25th at 12:00pm
>> EDT.  During the telcon, we'll be following up from the meeting about
>> threading (notes below).  Before the meeting, we're supposed to think
>> about a couple of different issues regarding threads and the MPI spec,
>> including:
>> 
>> * which MPI functions have functionality / usability deficiencies if an
>> MPI does not support MPI_THREAD_MULTIPLE
>> * which MPI functions have use cases which present threading issues in
>> the presence of threads?
>> 
>> Some notes from this week's working group meeting:
>> 
>> * Jeff H. brought up the fact that library initialization is impossible
>> to do in a thread safe manner.  Query_thread, for example, may not be
>> called from the non-main thread in MPI_THREAD_FUNNELED (or by two threads
>> simultaneously in MPI_THREAD_SERIALIZED).
>> * The tools working group has some use cases where the Intialized / Init
>> race condition is problematic
>> * Fab would like us to revive the generalized request discussion; it's a
>> feature that lacks a significant amount of usability without
>> MPI_THREAD_MULTIPLE, but MPI_THREAD_MULTIPLE's support is slow in
>> expanding.
>> * Bill brought up the concern that the forum has the tendency to be
>> two-faced about threads.  We talk about "just use a thread" when trying to
>> solve a particular problem, then are reluctant to require threads as part
>> of the model; we should figure out how to deal with that.
>> 
>> Brian
>> 
>> --
>> Brian W. Barrett
>> Scalable System Software Group
>> Sandia National Laboratories