Thanks Bill and Pavan.
I was having trouble seeing how (especially) a nonblocking ready send could be
guaranteed to occur before the matching receive but since I only saw the
problem on Titan I was wondering if I had missed something.
Apparently, I was just really lucky on the other
Pavan is correct; the program is buggy. Here’s an example
process 1 process 2
start(recv) /* something causes a delay at process 2 */
start(rsend)
wait(all)
start(recv)
….
In this case, the rsend on process 1 occurs before the recv is
Brian,
Assuming all processes are doing the same code as below, I think the user
program is incorrect and you were just getting lucky with the other
implementations.
Specifically, there’s nothing stopping the rsend from a process to reach the
other process before it posted the corresponding
Hi all,
(trying again; I thought this address was subscribed to the list but maybe not.
Sorry if this is a duplicate)
I have a user-provided code that uses persistent ready sends. (Don’t ask. I
don’t have an answer to “why?”. Maybe it actually helped on some machine
sometime in the past?)
