send vs asend?

Question

What is the practical difference between send and asend? 

I get that one is synchronous and the other is asynchronous, but what does that mean in practice? All the default message blocks are "non-blocking" and will always accept messages, so even if you call send it will just drop of the message on the input buffer and continue executing. So then what is the difference between calling send and asend on e.g. a unbounded_buffer or a overwrite_buffer? 

Answer 1

Hello,

Asend drops off the message in the input buffer. Send processes the message before returning.

 So for example, consider the following snippet executing on a single thread.

send(unbounded_buffer, data);

try_receive(msgBlock, value)) // This is guaranteed to succeed (return true)

asend(unbounded_buffer, data)

try_receive(msgBlock, value)) // This could return false because the message hasn’t been yet “processed” by the unbounded_buffer.

 This is even more apparent with a transformer block. Send would wait for the transform function to complete execution of the message being sent before returning. Asend would return immediately (after inserting the message into the queue).

---

Rahul V. Patil

Answer 2

Also, since you have many questions around using Agents and Messaging, would you be interested in 1 hour online chat with our devs? I would also love to hear on how you are using the PPL and runtime.

[My email is r_ a_ h_ u_ l   d o t    p_ a_ t_ i_ l    a t    m_ i_ c_ r_ o_ s_ o_ f_ t_ . c_ o_ m  (delete all underscores and spaces; replace d o t with the character "." ).]

---

Rahul V. Patil

Answer 3

" This is even more apparent with a transformer block. Send would wait for the transform function to complete execution of the message being sent before returning. Asend would return immediately (after inserting the message into the queue)."

The example above cleared up for me the difference. I assume that using send would be more cache friendly since the tasks tend to execute on the calling context? While asend would allow one to "fire and forget".

Answer 4

Glad that it helped.

Re: Cache friendly

The calling context picks up tasks in only special cases (like task_group.wait()) and not in all blocking cases. Though, the underlying virtual processor, will pick up a cache warm task in general for all cases of blocking. In general, Cache benefits really depends on the workload and number of processors.

---

Rahul V. Patil