[pooma-dev] [Q] ReceiveIterate asymmetry bug?

[Richard Guenther]

It seems nobody is interested in this - but to summarize, with messaging
using Cheetah the message requesting machinery in Tulip/SendReceive.h uses
possibly stale memory if reordering iterates is allowed (which is the
default for --messaging config).

A patch like the following is needed (which basically kills out of order
processing of these messages), or a more elaborate fix like constructing
the needed view in extra memory and freeing that inside the matching
handler.

Richard.

===== SendReceive.h 1.4 vs edited =====
--- 1.4/r2/src/Tulip/SendReceive.h	Tue Dec  2 18:40:12 2003
+++ edited/SendReceive.h	Tue Dec  9 11:36:34 2003
@@ -134,7 +134,7 @@
  * ReceiveIterate requests a write lock on a piece of data.  When that lock
  * is granted, we register the data with the cheetah matching handler which
  * will fill the block when a message arrives.  The write lock is released
- * by the matching handler.
+ * by the destructor after ensuring we're finished with processing.
  */

 template<class View, class IncomingView>
@@ -166,65 +166,41 @@
     engineFunctor(view, writeReq);

     Pooma::addIncomingMessage();
+    ready_m = false;
   }

   virtual ~ReceiveIterate()
   {
-  }
-
-  // If we're using cheetah, but don't support out-of-order execution, then
-  // the run method of this iterate must block until the message has been
-  // received.  Unlike typical iterates, the work implied by this iterate
-  // isn't actually performed in the run method.  The run method merely
-  // registers a method that gets handled by cheetah when the appropriate
-  // message arrives.
-
-#if !POOMA_REORDER_ITERATES
-
-  bool ready_m;
-
-  static void handle(This_t *me, IncomingView &viewMessage)
-  {
-    apply(me->view_m, viewMessage);
-    me->ready_m = true;
-  }
-
-  virtual void run()
-  {
-    ready_m = false;
-    Pooma::remoteEngineHandler()->request(fromContext_m, tag_m,
-					  This_t::handle, this);
-
+    // Be sure we have received the data.
     while (!ready_m)
-    {
       Pooma::poll();
-    }
+
+    // Release the received block:
+    DataObjectRequest<WriteRelease> writeReq;
+    engineFunctor(viewLocal, writeReq);
+    Pooma::gotIncomingMessage();
   }

-#else
+  // Unlike typical iterates, the work implied by this iterate
+  // isn't actually performed in the run method.  The run method merely
+  // registers a method that gets handled by cheetah when the appropriate
+  // message arrives. So we need to be careful we finished processing
+  // before we destruct the iterate.

   virtual void run()
   {
     Pooma::remoteEngineHandler()->request(fromContext_m, tag_m,
-					  This_t::apply, view_m);
+					  This_t::apply, this);
   }

-#endif
-
 private:

-  static void apply(const View &viewLocal, IncomingView &viewMessage)
+  static void apply(This_t *me, IncomingView &viewMessage)
   {
     // For now, we just copy the message into the brick accepting the data.
-
-    KernelEvaluator<InlineKernelTag>::evaluate(viewLocal, OpAssign(),
+    KernelEvaluator<InlineKernelTag>::evaluate(me->view_m, OpAssign(),
 					       viewMessage);
-
-    // Release the received block:
-    DataObjectRequest<WriteRelease> writeReq;
-    engineFunctor(viewLocal, writeReq);
-
-    Pooma::gotIncomingMessage();
+    me->ready_m = true;
   }

   // Context we're sending the data to.
@@ -239,6 +215,10 @@
   // engine).;

   View view_m;
+
+  // Flag if we have received the data.
+
+  bool ready_m;
 };

 /**