October 2011 - mpiwg-ft - mailman3.cels.anl.gov

Re: [Mpi3-ft] Latest version of chapter
by Sur, Sayantan 21 Oct '11

21 Oct '11

17.5.1:11-12 - "The error handler function will be called by the MPI implementation from within the context of some MPI function that was called by the user." Maybe we should that error handlers are called from MPI functions that are associated with that comm/file/win? > -----Original Message----- > From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:mpi3-ft- > bounces(a)lists.mpi-forum.org] On Behalf Of Josh Hursey > Sent: Friday, October 21, 2011 10:28 AM > To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group > Subject: Re: [Mpi3-ft] Latest version of chapter > > I just wanted to note that we want to distribute a copy of this > chapter to the MPI Forum before the meeting. As such we are planning > on sending out a copy at COB today (so Friday ~5:00 pm EDT) so that > people have an opportunity to look at the document before the Monday > plenary. So please send any edits or comments before COB today, so we > can work them into the draft. > > We will post the draft to the ticket, so that people know where to > look for the current draft. > > Thanks, > Josh > > > > On Thu, Oct 20, 2011 at 7:06 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> > wrote: > > > > Here's the latest version of the FT chapter is on the wiki (it's in a > new location on the main FT page under "ticket #276". ï¿½Please have a > look and comment. > > > > Here's a direct link to the PDF: > > ï¿½ ï¿½https://svn.mpi-forum.org/trac/mpi-forum-web/raw- > attachment/wiki/FaultToleranceWikiPage/ft.pdf > > > > Here's a summary of the changes Josh and I made: > > > > * Minor wording touchups > > * Added new semantic for MPI_ANY_SOURCE with the > MPI_ERR_ANY_SOURCE_DISABLED error code > > * Coverted wording for all comm, win, fh creation operations to not > require collectively active communicators (eliminate requirement for > synchronization) > > * Added missing reader_lock to ANY_SOURCE example > > * Added case for MPI_WIN_TEST > > > > and > > > > One-sided section > > ï¿½ ï¿½clarified that window creation need not be blocking > > ï¿½ ï¿½clarified that RMA ops might not complete correctly even if > > ï¿½ ï¿½ ï¿½synchronization ops complete without error due to process > > ï¿½ ï¿½ ï¿½failures > > Process failure notification > > ï¿½ ï¿½Added section describing new functions to add callbacks to comms, > > ï¿½ ï¿½ ï¿½wins and files that are called when proc failure is detected > > Other wordsmithing/cleanup changes > > > > -d > > _______________________________________________ > > mpi3-ft mailing list > > mpi3-ft(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > > > > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] Latest version of chapter
by Josh Hursey 21 Oct '11

21 Oct '11

I just wanted to note that we want to distribute a copy of this chapter to the MPI Forum before the meeting. As such we are planning on sending out a copy at COB today (so Friday ~5:00 pm EDT) so that people have an opportunity to look at the document before the Monday plenary. So please send any edits or comments before COB today, so we can work them into the draft. We will post the draft to the ticket, so that people know where to look for the current draft. Thanks, Josh On Thu, Oct 20, 2011 at 7:06 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: > > Here's the latest version of the FT chapter is on the wiki (it's in a new location on the main FT page under "ticket #276". ï¿½Please have a look and comment. > > Here's a direct link to the PDF: > ï¿½ ï¿½https://svn.mpi-forum.org/trac/mpi-forum-web/raw-attachment/wiki/FaultTo… > > Here's a summary of the changes Josh and I made: > > * Minor wording touchups > * Added new semantic for MPI_ANY_SOURCE with the MPI_ERR_ANY_SOURCE_DISABLED error code > * Coverted wording for all comm, win, fh creation operations to not require collectively active communicators (eliminate requirement for synchronization) > * Added missing reader_lock to ANY_SOURCE example > * Added case for MPI_WIN_TEST > > and > > One-sided section > ï¿½ ï¿½clarified that window creation need not be blocking > ï¿½ ï¿½clarified that RMA ops might not complete correctly even if > ï¿½ ï¿½ ï¿½synchronization ops complete without error due to process > ï¿½ ï¿½ ï¿½failures > Process failure notification > ï¿½ ï¿½Added section describing new functions to add callbacks to comms, > ï¿½ ï¿½ ï¿½wins and files that are called when proc failure is detected > Other wordsmithing/cleanup changes > > -d > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

[Mpi3-ft] Latest version of chapter
by Darius Buntinas 20 Oct '11

20 Oct '11

Here's the latest version of the FT chapter is on the wiki (it's in a new location on the main FT page under "ticket #276". Please have a look and comment. Here's a direct link to the PDF: https://svn.mpi-forum.org/trac/mpi-forum-web/raw-attachment/wiki/FaultToler… Here's a summary of the changes Josh and I made: * Minor wording touchups * Added new semantic for MPI_ANY_SOURCE with the MPI_ERR_ANY_SOURCE_DISABLED error code * Coverted wording for all comm, win, fh creation operations to not require collectively active communicators (eliminate requirement for synchronization) * Added missing reader_lock to ANY_SOURCE example * Added case for MPI_WIN_TEST and One-sided section clarified that window creation need not be blocking clarified that RMA ops might not complete correctly even if synchronization ops complete without error due to process failures Process failure notification Added section describing new functions to add callbacks to comms, wins and files that are called when proc failure is detected Other wordsmithing/cleanup changes -d

1 0

Re: [Mpi3-ft] one sided
by Pavan Balaji 19 Oct '11

19 Oct '11

FYI, you cannot "require" some behavior from MPI through an info argument. It is perfectly legitimate for the MPI implementation to completely ignore any info arguments passed. They are just user hints. -- Pavan On 10/19/2011 07:59 AM, Josh Hursey wrote: > Let's be sure to talk about this on today's call. I have some other > one-sided notes that I would like to go over as well. > > It would be fairly easy to support both modes since the MPI_Win_create > operation takes an info argument. We could define a key (similar to > what they have done for other operations) that either loosens or > tightens the semantics depending on what the default behavior should > be. > > I think it is ok to have a non-synchronizing option, just as long as > we have clear semantics for when the window is not created at all > processes due to some process failure - or if the window is always > created regardless of emerging failure then we might avoid this issue, > but that might require some additional clarification. > > Thanks, > Josh > > On Wed, Oct 19, 2011 at 4:11 AM, Supalov, Alexander > <alexander.supalov(a)intel.com> wrote: >> Thanks. Why not having two calls or modes of operation to cover both? >> >> -----Original Message----- >> From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Darius Buntinas >> Sent: Tuesday, October 18, 2011 9:57 PM >> To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group >> Subject: [Mpi3-ft] one sided >> >> >> I got some feedback from Jim and Pavan on the one-sided section. One thing Jim pointed out was that we don't want to make window creation synchronizing, and the fail-or-succeed everywhere requirement would do that. >> >> If we say that window creation should not fail due to failed processes, that would accomplish the same thing: If a window is created by a correct program, then it will succeed at all live processes. Note that if an incorrect program specifies invalid parameters then the window creation may fail at some processes and succeed at others, but this is what we already have today. >> >> However, it's possible that some implementations cannot satisfy this requirement because, e.g., they do collectives as part of the operation. So maybe we should have two options: >> >> Either: >> window creation won't fail because if failed processes >> or >> window creation will either succeed or fail everywhere and if window creation fails at >> any process it fails at every process >> >> -d >> >> >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >> -------------------------------------------------------------------------------------- >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> Sitz der Gesellschaft: Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 >> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >> >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >> >> > > > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-ft] one sided
by Josh Hursey 19 Oct '11

19 Oct '11

Let's be sure to talk about this on today's call. I have some other one-sided notes that I would like to go over as well. It would be fairly easy to support both modes since the MPI_Win_create operation takes an info argument. We could define a key (similar to what they have done for other operations) that either loosens or tightens the semantics depending on what the default behavior should be. I think it is ok to have a non-synchronizing option, just as long as we have clear semantics for when the window is not created at all processes due to some process failure - or if the window is always created regardless of emerging failure then we might avoid this issue, but that might require some additional clarification. Thanks, Josh On Wed, Oct 19, 2011 at 4:11 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: > Thanks. Why not having two calls or modes of operation to cover both? > > -----Original Message----- > From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Darius Buntinas > Sent: Tuesday, October 18, 2011 9:57 PM > To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group > Subject: [Mpi3-ft] one sided > > > I got some feedback from Jim and Pavan on the one-sided section. ï¿½One thing Jim pointed out was that we don't want to make window creation synchronizing, and the fail-or-succeed everywhere requirement would do that. > > If we say that window creation should not fail due to failed processes, that would accomplish the same thing: ï¿½If a window is created by a correct program, then it will succeed at all live processes. ï¿½Note that if an incorrect program specifies invalid parameters then the window creation may fail at some processes and succeed at others, but this is what we already have today. > > However, it's possible that some implementations cannot satisfy this requirement because, e.g., they do collectives as part of the operation. ï¿½So maybe we should have two options: > > ï¿½Either: > ï¿½ ï¿½window creation won't fail because if failed processes > ï¿½or > ï¿½ ï¿½window creation will either succeed or fail everywhere and if window creation fails at > ï¿½ ï¿½any process it fails at every process > > -d > > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] one sided
by Supalov, Alexander 19 Oct '11

19 Oct '11

Thanks. Why not having two calls or modes of operation to cover both? -----Original Message----- From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Darius Buntinas Sent: Tuesday, October 18, 2011 9:57 PM To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group Subject: [Mpi3-ft] one sided I got some feedback from Jim and Pavan on the one-sided section. One thing Jim pointed out was that we don't want to make window creation synchronizing, and the fail-or-succeed everywhere requirement would do that. If we say that window creation should not fail due to failed processes, that would accomplish the same thing: If a window is created by a correct program, then it will succeed at all live processes. Note that if an incorrect program specifies invalid parameters then the window creation may fail at some processes and succeed at others, but this is what we already have today. However, it's possible that some implementations cannot satisfy this requirement because, e.g., they do collectives as part of the operation. So maybe we should have two options: Either: window creation won't fail because if failed processes or window creation will either succeed or fail everywhere and if window creation fails at any process it fails at every process -d _______________________________________________ mpi3-ft mailing list mpi3-ft(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

[Mpi3-ft] FT WG Teleconference Wednesday @ Noon EDT
by Josh Hursey 18 Oct '11

18 Oct '11

Reminder that we have a teleconf tomorrow, Wednesday 10/19/2011, at Noon EDT. Date: October 19, 2011 Time: Noon EDT/New York Dial-in information: 877-801-8130 Code: 1044056 Agenda: - Run-Through Stabilization Proposal - MPI_ANY_SOURCE - One-sided semantics https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/run_through_stabilizat… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/run_through_stabilizat… - Notes from Sept. MPI Forum Meeting http://lists.mpi-forum.org/mpi3-ft/2011/09/0859.php - PDF Draft Preparation - Other items? Additional Agenda Items [if time permits]: - Process Recovery (Josh H.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/process_recovery_2 - MPI Forum notes discussion (?) http://lists.mpi-forum.org/mpi3-ft/2011/07/0805.php - Error to Fault changes proposal (Darius B.) http://lists.mpi-forum.org/mpi3-ft/2011/06/0773.php - Piggybacking? (Martin S.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Piggybacking - Network Channel Failure http://lists.mpi-forum.org/mpi3-ft/2011/06/0730.php - FT Query Interface http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php Next Meetings: * Oct. 19, 2011 (Teleconf) * Oct. 26, 2011 (MPI Forum Meeting) * Nov. 9, 2011 (Teleconf) * Nov. 30, 2011 (Teleconf) Respond to the list if you have any additional topics that you would like to discuss. -- Josh -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

[Mpi3-ft] one sided
by Darius Buntinas 18 Oct '11

18 Oct '11

I got some feedback from Jim and Pavan on the one-sided section. One thing Jim pointed out was that we don't want to make window creation synchronizing, and the fail-or-succeed everywhere requirement would do that. If we say that window creation should not fail due to failed processes, that would accomplish the same thing: If a window is created by a correct program, then it will succeed at all live processes. Note that if an incorrect program specifies invalid parameters then the window creation may fail at some processes and succeed at others, but this is what we already have today. However, it's possible that some implementations cannot satisfy this requirement because, e.g., they do collectives as part of the operation. So maybe we should have two options: Either: window creation won't fail because if failed processes or window creation will either succeed or fail everywhere and if window creation fails at any process it fails at every process -d

1 0

Re: [Mpi3-ft] MPI_ANY_SOURCE
by Darius Buntinas 13 Oct '11

13 Oct '11

Yes, MPI_ERR_PENDING is a good example! So we're not entering new territory by giving an "error" for an active request. -d On Oct 13, 2011, at 9:46 AM, Josh Hursey wrote: > By returning an error we are completing the ANY_SOURCE request - isn't > that the problem we are trying to work around. The problem was that > ANY_SOURCE would complete in error causing the matching issues. > > That is unless you are suggesting that we give the error the same > semantics as MPI_ERR_PENDING. MPI_ERR_PENDING kinda works like a > warning. For wait_all, the non-completed messages have a > status.MPI_ERROR = MPI_ERR_PENDING to indicate that they are still > outstanding, and need to be waited on. This way the user can > distinguish between requests that are complete (either successfully or > in error) and those that are not complete yet. So if we have a > different error with similar semantics, e.g., > MPI_ERR_ANY_SOURCE_DISABLED, we can say that it is similar to > MPI_ERR_PENDING in that the request is not complete. The user can then > decide to continue waiting or cancel the request. Is that what you > were thinking? > > -- Josh > > On Tue, Oct 11, 2011 at 4:24 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: >> I think we can do this without a warning, just by using an error: If a wait (or wait_all, test, etc) is called with an anysource request while the req's communicator is anysource disabled, then the function will return an error (maybe something like MPI_ERR_ANYSOURCE_DISABLED). >> >> Of course in the wait_all case the app needs to be able to determine which req is the anysource on a disabled communicator. We may be able to help the user here by using the status array. >> >> -d >> >> On Oct 11, 2011, at 3:16 PM, Darius Buntinas wrote: >> >>> >>> I think you're right Josh, the blocking version wouldn't need to be changed. >>> >>> For the nonblocking version, wouldn't we only need to lock around the Wait, not between the Recv and Wait? If we're worried about hanging in a blocking Wait, I think we just need to check for all-clients-failed before calling Wait. If anysources are reenabled by another thread before this thread calls Wait, that's OK, so long as the thread checks first. >>> >>> Here's a function a user could implement to use whenever waiting on an anysource: >>> >>> int My_AS_MPI_Wait(MPI_Request *req, MPI_Status *status) >>> { >>> while(1) { >>> reader_lock(); >>> if (my_cnt != recognize_cnt) { >>> /* New failures were detected */ >>> /* check failed_group and decide if ok to continue */ >>> if (ok_to_continue(req, failed_group) == FALSE) { >>> reader_unlock(); >>> return MPI_ERR_PROC_FAIL_STOP; >>> } >>> my_cnt == recognize_cnt; >>> } >>> err = MPI_Wait(req, status); >>> if (err == MPI_WARN_PROC_FAIL_STOP) { >>> /* Failure case */ >>> reader_unlock(); >>> writer_lock(); >>> if (my_cnt != recognize_cnt) { >>> /* another thread has already re-enabled wildcards */ >>> writer_unlock(); >>> continue; >>> } >>> MPI_Comm_reenable_any_source(comm, &failed_group); >>> ++recognize_cnt; >>> writer_unlock(); >>> continue; >>> } else { >>> reader_unlock(); >>> return MPI_ERR_PROC_FAIL_STOP; >>> } >>> reader_unlock(); >>> } >>> } >>> >>> -d >>> >> >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >> >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] MPI_ANY_SOURCE
by Josh Hursey 13 Oct '11

13 Oct '11

By returning an error we are completing the ANY_SOURCE request - isn't that the problem we are trying to work around. The problem was that ANY_SOURCE would complete in error causing the matching issues. That is unless you are suggesting that we give the error the same semantics as MPI_ERR_PENDING. MPI_ERR_PENDING kinda works like a warning. For wait_all, the non-completed messages have a status.MPI_ERROR = MPI_ERR_PENDING to indicate that they are still outstanding, and need to be waited on. This way the user can distinguish between requests that are complete (either successfully or in error) and those that are not complete yet. So if we have a different error with similar semantics, e.g., MPI_ERR_ANY_SOURCE_DISABLED, we can say that it is similar to MPI_ERR_PENDING in that the request is not complete. The user can then decide to continue waiting or cancel the request. Is that what you were thinking? -- Josh On Tue, Oct 11, 2011 at 4:24 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: > I think we can do this without a warning, just by using an error: ï¿½If a wait (or wait_all, test, etc) is called with an anysource request while the req's communicator is anysource disabled, then the function will return an error (maybe something like MPI_ERR_ANYSOURCE_DISABLED). > > Of course in the wait_all case the app needs to be able to determine which req is the anysource on a disabled communicator. ï¿½We may be able to help the user here by using the status array. > > -d > > On Oct 11, 2011, at 3:16 PM, Darius Buntinas wrote: > >> >> I think you're right Josh, the blocking version wouldn't need to be changed. >> >> For the nonblocking version, wouldn't we only need to lock around the Wait, not between the Recv and Wait? ï¿½If we're worried about hanging in a blocking Wait, I think we just need to check for all-clients-failed before calling Wait. ï¿½If anysources are reenabled by another thread before this thread calls Wait, that's OK, so long as the thread checks first. >> >> Here's a function a user could implement to use whenever waiting on an anysource: >> >> int My_AS_MPI_Wait(MPI_Request *req, MPI_Status *status) >> { >> ï¿½ ï¿½while(1) { >> ï¿½ ï¿½ ï¿½ ï¿½reader_lock(); >> ï¿½ ï¿½ ï¿½ ï¿½if (my_cnt != recognize_cnt) { >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½/* New failures were detected */ >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½/* check failed_group and decide if ok to continue */ >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½if (ok_to_continue(req, failed_group) == FALSE) { >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½reader_unlock(); >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½return MPI_ERR_PROC_FAIL_STOP; >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½} >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½my_cnt == recognize_cnt; >> ï¿½ ï¿½ ï¿½ ï¿½} >> ï¿½ ï¿½ ï¿½ ï¿½err = MPI_Wait(req, status); >> ï¿½ ï¿½ ï¿½ ï¿½if (err == MPI_WARN_PROC_FAIL_STOP) { >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½/* Failure case */ >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½reader_unlock(); >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½writer_lock(); >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½if (my_cnt != recognize_cnt) { >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½/* another thread has already re-enabled wildcards */ >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½writer_unlock(); >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½continue; >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½} >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½MPI_Comm_reenable_any_source(comm, &failed_group); >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½++recognize_cnt; >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½writer_unlock(); >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½continue; >> ï¿½ ï¿½ ï¿½ ï¿½} else { >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½reader_unlock(); >> ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½return MPI_ERR_PROC_FAIL_STOP; >> ï¿½ ï¿½ ï¿½ ï¿½} >> ï¿½ ï¿½ ï¿½ ï¿½reader_unlock(); >> ï¿½ ï¿½} >> } >> >> -d >> > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0