It's removed because it's ambiguous/meaningless. If you want to state something specific, state something specific.
On Mar 3, 2015, at 3:40 PM, Jeff Hammond <[email protected]> wrote:
I wrote the primary wording. Ball is in your court to propose an alternative if you don't like my version. But it has to preserve the intent of the original text, not just remove it because it makes you uncomfortable.
Jeff
On Tue, Mar 3, 2015 at 3:38 PM, Balaji, Pavan <[email protected]> wrote:
Please suggest alternate wording.
-- Pavan
On Mar 3, 2015, at 5:32 PM, Jeff Hammond <[email protected]> wrote:
I could be wrong, but if I wrote that sentence, I meant what George said and not anything else.
Jeff
On Tue, Mar 3, 2015 at 3:24 PM, Balaji, Pavan <[email protected]> wrote:
This was not what was voted on. The vote was based on the PDF, which doesn't contain this text. So the change is incorrect and comes under the chapter committee prerogative.
Coming to the change itself, for environments that don't even allow multiple threads to exist, this is trivial for MPI implementations to provide. The concern is that before MPI_INIT_THREAD, I do not know if I can use THREAD_MULTIPLE or not. The user does not know and should be able to call these functions either way.
-- Pavan
On Mar 3, 2015, at 4:56 PM, George Bosilca <[email protected]> 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, but to implementations that have no thread support at all (they don't even link against pthreads). Forcing such an implementation to provide thread safety for a handful of functions is unreasonable.
George.
On Tue, Mar 3, 2015 at 5:30 PM, Balaji, Pavan <[email protected]> wrote:
Thanks. Jim/Jeff/Aurelien?
On Mar 3, 2015, at 4:29 PM, Daniel Holmes <[email protected]> wrote:
I agree that this sentence should not be in the standard.
Cheers, Dan.
On 03/03/2015 14:24, Balaji, Pavan wrote:
The Forum was not entirely happy with the chapter committee change on the EI chapter. Specifically, the following sentence that was added into the pdf should be removed:
"Implementations that do not support threads are not required to support the calling of these functions from threads."
This is in direct contradiction to the fact that the mentioned functions should work correctly without knowing whether threads are there or not. I plan to remove it. Please let me know what you think.
-- Pavan
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji
_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
-- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: [email protected]
*Please consider the environment before printing this email.*
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji
_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji
_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji
_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/