[mpich-discuss] What is the difference between MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED

[Thakur, Rajeev]

> Can you please let me know the answer to the second part of the question below?  Is it OK for the code to use MPI_THREAD_SINGLE for the situation described below?

The MPI standard says you should not use THREAD_SINGLE in that case. 

Rajeev


On Jul 14, 2014, at 3:05 PM, Raghu Reddy <rreddypsc at gmail.com> wrote:

> Hi Rajeev,
> 
> 
> Thank you for your prompt response.
> 
> 
> I understand why it is helpful to indicate there are other threads, which was the first part of my question.
> 
> 
> Can you please let me know the answer to the second part of the question below?  Is it OK for the code to use MPI_THREAD_SINGLE for the situation described below?
> 
> 
> Thanks,
> 
> Raghu
> 
> 
> 
> On Sun, Jul 13, 2014 at 2:53 PM, Thakur, Rajeev <thakur at mcs.anl.gov> wrote:
> It is so that the MPI implementation knows that other user threads exist. It can then invoke thread-safe versions of C or Fortran library calls if necessary.
> 
> Rajeev
> 
> 
> On Jul 13, 2014, at 8:04 AM, rreddypsc at gmail.com wrote:
> 
> > Sorry about resurrecting a topic that is more than a month old.
> >
> > I was also under the impression that as long as all MPI calls are done outside of the threaded regions, using MPI_THREAD_SINGLE was sufficient. Based on the discussion below it looks like even in those situations one has to use MPI_THREAD_FUNNELED.
> >
> > For my understanding is it possible to briefly explain why this is the case?  Is this still required, for example, if there is no MPI activity happening at all (for example no asynchronous communication is happening when any part of the threaded code is active)?
> >
> > In particular, I'm thinking about:
> >
> >       MPI comm start
> >       MPI comm end
> >
> >       threaded work (OpenMP for example with no MPI of any kind)
> >
> >       MPI comm start
> >       MPI comm end
> >       ...etc
> >
> > The reason for this question is that I have a feeling that a lot of other users may be of the same opinion and would benefit from clarification.
> >
> > TIA for clarification!
> >
> > Raghu
> >
> >
> > --On Monday, June 2, 2014 12:58 AM +0000 "Balaji, Pavan" <balaji at anl.gov> wrote:
> >
> >>
> >> On May 30, 2014, at 12:30 PM, Boisvert, Sebastien <boisvert at anl.gov>
> >> wrote:
> >>> On Friday, May 30, 2014 12:26 PM, discuss-bounces at mpich.org
> >>> [discuss-bounces at mpich.org] on behalf of Rajeev Thakur
> >>> [thakur at mcs.anl.gov] wrote:
> >>>> To: discuss at mpich.org
> >>>> Subject: Re: [mpich-discuss] What is the        difference      between
> >>>> MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED
> >>>>
> >>>> It shouldn't, but what does it return in your program?
> >>>
> >>> I am currently using MPI_Init (I thought it was OK if only the main
> >>> thread calls MPI functions).
> >>>
> >>> Code->
> >>> https://github.com/GeneAssembly/biosal/blob/master/engine/node.c#L33
> >>
> >> If you initialize with MPI_INIT, the MPI implementation can choose to
> >> provide whatever thread-level it likes.  There are two options for you:
> >>
> >> Option 1:
> >>
> >> MPI_INIT  /* tell MPI to give you what it can */
> >> MPI_QUERY_THREAD /* ask for what you got */
> >> if (less than FUNNELED) abort;
> >>
> >> Option 2:
> >>
> >> MPI_INIT_THREAD(FUNNELED, &provided); /* tell MPI to give you FUNNELED */
> >> if (provided < FUNNELED) abort;
> >>
> >> Option 2 is cleaner since you gave MPI a hint that you would like to have
> >> FUNNELED level.
> >>
> >>  — Pavan
> >>
> >> _______________________________________________
> >> discuss mailing list     discuss at mpich.org
> >> To manage subscription options or unsubscribe:
> >> https://lists.mpich.org/mailman/listinfo/discuss
> >
> >
> > _______________________________________________
> > discuss mailing list     discuss at mpich.org
> > To manage subscription options or unsubscribe:
> > https://lists.mpich.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss