<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Combining multithreading and IntelMPI in Intel® MPI Library</title>
    <link>https://community.intel.com/t5/Intel-MPI-Library/Combining-multithreading-and-IntelMPI/m-p/1069819#M4666</link>
    <description>&lt;P&gt;Hi all,&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### The problem at hand ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;I am trying to model a workflow where a manager process and multiple worker processes have multiple "conversations" simultaneously.&lt;BR /&gt;
	&lt;BR /&gt;
	The manager process had a "main thread" that sends messages to each workers, waits for them to do something and picks up the results (this entire pattern being repeated many times).&lt;BR /&gt;
	It also has a secondary thread that listens on messages from the workers and processes them independently of the main computations (sending back a status to the workers).&lt;BR /&gt;
	The secondary thread is very simple: it looks as follows (pseudo-code):&lt;/P&gt;

&lt;P&gt;while (true) {&lt;/P&gt;

&lt;PRE class="brush:plain;"&gt;    status = probe(comm)
    if (status.tag == relatedToThisThread) {
        msg = receive(comm, status.tag, status.source)
        status = process(msg)
        send(comm, status)
    }
}&lt;/PRE&gt;

&lt;P&gt;&lt;BR /&gt;
	From the worker's point of view, they may issue calls to the secondary thread at any time in the middle of their work or between two pieces of work.&lt;BR /&gt;
	&lt;BR /&gt;
	I tried 2 different approaches so far to model this workflow:&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### Case 1: 1 Manager( 1 communicator, 2 threads); N Workers (1 communicator, 1 thread each) ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;The Manager has one communicator with which it can communicate with all Workers.&lt;BR /&gt;
	Both threads share a reference to the same communicator that is hooked to the N Worker processes.&lt;BR /&gt;
	&lt;BR /&gt;
	I sometimes get failures where even though I am calling "receive" with a given tag and source; messages addressed to different threads seem to get intermingled occasionally (can be made reproducible by having a large number of worker processes).&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### Case 2: 1 Manager ( N communicators, N + 1 threads); N Workers (1 communicator, 1 thread each) ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;&lt;BR /&gt;
	The Manager has one communicator per worker (mostly to improve fault tolerance). Each communicator is referenced to by both the main thread and one of the N secondary threads.&lt;BR /&gt;
	&lt;BR /&gt;
	This seems more reliable. In particular, it scales better with a large number of workers. However, I cannot convince myself that the same problem I observed in case 1 cannot happen here.&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### My question ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;I was wondering if anyone had had to deal with a similar situation. What strategy did you use to solve these issues?&lt;BR /&gt;
	&lt;BR /&gt;
	From my initial readings, it seems that MPI_Mprobe and MPI_Mreceive may be the key to solving this problem; but I would welcome any suggestion while I'm experimenting with this situation.&lt;/P&gt;

&lt;P&gt;&lt;BR /&gt;
	&lt;BR /&gt;
	&lt;BR /&gt;
	&lt;BR /&gt;
	&lt;BR /&gt;
	&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 08 Sep 2016 14:40:48 GMT</pubDate>
    <dc:creator>Pierre_C_1</dc:creator>
    <dc:date>2016-09-08T14:40:48Z</dc:date>
    <item>
      <title>Combining multithreading and IntelMPI</title>
      <link>https://community.intel.com/t5/Intel-MPI-Library/Combining-multithreading-and-IntelMPI/m-p/1069819#M4666</link>
      <description>&lt;P&gt;Hi all,&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### The problem at hand ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;I am trying to model a workflow where a manager process and multiple worker processes have multiple "conversations" simultaneously.&lt;BR /&gt;
	&lt;BR /&gt;
	The manager process had a "main thread" that sends messages to each workers, waits for them to do something and picks up the results (this entire pattern being repeated many times).&lt;BR /&gt;
	It also has a secondary thread that listens on messages from the workers and processes them independently of the main computations (sending back a status to the workers).&lt;BR /&gt;
	The secondary thread is very simple: it looks as follows (pseudo-code):&lt;/P&gt;

&lt;P&gt;while (true) {&lt;/P&gt;

&lt;PRE class="brush:plain;"&gt;    status = probe(comm)
    if (status.tag == relatedToThisThread) {
        msg = receive(comm, status.tag, status.source)
        status = process(msg)
        send(comm, status)
    }
}&lt;/PRE&gt;

&lt;P&gt;&lt;BR /&gt;
	From the worker's point of view, they may issue calls to the secondary thread at any time in the middle of their work or between two pieces of work.&lt;BR /&gt;
	&lt;BR /&gt;
	I tried 2 different approaches so far to model this workflow:&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### Case 1: 1 Manager( 1 communicator, 2 threads); N Workers (1 communicator, 1 thread each) ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;The Manager has one communicator with which it can communicate with all Workers.&lt;BR /&gt;
	Both threads share a reference to the same communicator that is hooked to the N Worker processes.&lt;BR /&gt;
	&lt;BR /&gt;
	I sometimes get failures where even though I am calling "receive" with a given tag and source; messages addressed to different threads seem to get intermingled occasionally (can be made reproducible by having a large number of worker processes).&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### Case 2: 1 Manager ( N communicators, N + 1 threads); N Workers (1 communicator, 1 thread each) ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;&lt;BR /&gt;
	The Manager has one communicator per worker (mostly to improve fault tolerance). Each communicator is referenced to by both the main thread and one of the N secondary threads.&lt;BR /&gt;
	&lt;BR /&gt;
	This seems more reliable. In particular, it scales better with a large number of workers. However, I cannot convince myself that the same problem I observed in case 1 cannot happen here.&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;### My question ###&lt;/STRONG&gt;&lt;/P&gt;

&lt;P&gt;I was wondering if anyone had had to deal with a similar situation. What strategy did you use to solve these issues?&lt;BR /&gt;
	&lt;BR /&gt;
	From my initial readings, it seems that MPI_Mprobe and MPI_Mreceive may be the key to solving this problem; but I would welcome any suggestion while I'm experimenting with this situation.&lt;/P&gt;

&lt;P&gt;&lt;BR /&gt;
	&lt;BR /&gt;
	&lt;BR /&gt;
	&lt;BR /&gt;
	&lt;BR /&gt;
	&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 08 Sep 2016 14:40:48 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-MPI-Library/Combining-multithreading-and-IntelMPI/m-p/1069819#M4666</guid>
      <dc:creator>Pierre_C_1</dc:creator>
      <dc:date>2016-09-08T14:40:48Z</dc:date>
    </item>
    <item>
      <title>Would status happen to be</title>
      <link>https://community.intel.com/t5/Intel-MPI-Library/Combining-multithreading-and-IntelMPI/m-p/1069820#M4667</link>
      <description>&lt;P&gt;Would status happen to be shared between the threads?&lt;/P&gt;

&lt;P&gt;Jim Dempsey&lt;/P&gt;</description>
      <pubDate>Sat, 17 Sep 2016 13:22:19 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-MPI-Library/Combining-multithreading-and-IntelMPI/m-p/1069820#M4667</guid>
      <dc:creator>jimdempseyatthecove</dc:creator>
      <dc:date>2016-09-17T13:22:19Z</dc:date>
    </item>
  </channel>
</rss>

