[mpiwg-hybridpm] Changes to the EI chapter

Jeff Hammond jeff.science at gmail.com
Tue Mar 3 17:46:12 CST 2015

On Tue, Mar 3, 2015 at 3:42 PM, Jeff Squyres (jsquyres)
<jsquyres at cisco.com> wrote:
> On Mar 3, 2015, at 2:56 PM, George Bosilca <bosilca at icl.utk.edu> wrote:
>> This change is a direct effect of the #357 ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357), that has been discussed and had received a successful vote (18 yes, 0 no, 1 abstain).
>> Removing this particular part of the paragraph does not clarify all conflicts of this section. Few lines above there is an even bolder statement claiming that "Therefore, \MPI/ implementations are not required to be thread compliant as defined in this section." So to thread or not to thread?
>> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED,
> Where is that defined?  This is a question that came out of the forum: "What exactly does it mean to 'not support threads'?  Every process has at least one thread."

Ugh.  Seriously?  MPI-1 "did not support threads".  It's pretty obvious.

>>  but to implementations that have no thread support at all (they don't even link against pthreads).
> Not linking against pthreads doesn't mean anything -- every process still has at least 1 thread.

You are making the semantic link between an OS process and a thread in
CS lexicon.  That's really not helpful here.

>> Forcing such an implementation to provide thread safety for a handful of functions is unreasonable.
> That was the whole point of the ticket: these functions are *always* thread safe.
> ...which is what Jeff Hammond wanted.  :-)

Then we are requiring ALL implementations to support threads.  You
want to make that rather huge change to MPI as part of dickering over
this sentence?

Jeff Hammond
jeff.science at gmail.com

More information about the mpiwg-hybridpm mailing list