[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
http://jeffhammond.github.io/



More information about the mpiwg-hybridpm mailing list