Hi Andrew,<div><br></div><div>Thank you very much for your response. Now everything is much clearer. What was happening was exactly that.</div><div><br></div><div>So I tried the two variants. First, in the single-threaded one, I used the continuation closure associated to the message to trigger the callback when the message is sent. Just like the idctest example you were telling. In that case it's working perfectly. So this may solve my problem, although things get a bit more complicated.</div>
<div><br></div><div>I would better try the multi-threaded version, so I created one extra thread per core just dispatching messages from the default waitset, as you suggested. However, in this case the problem doesn't get solved. The transmit queue fills and there is no more space after 32 messages. I'm wondering if I'm waiting in the correct waitset. You said there is an incoming waitset? Is it different from the default one?<br>
<br></div><div>The "dispatcher" thread looks like this:</div><div><br></div><div><div>static int dispatch_thread(void *p)</div><div>{</div><div> while (1) event_dispatch(get_default_waitset());</div><div><br>
</div><div> return 0;</div><div>}</div></div><div><br></div><div><br></div><div>Thank you again for your help!</div><div><br></div><div>zeus.</div><div><br></div><div> <br><div class="gmail_quote">El 17 de julio de 2011 19:54, Andrew Baumann <span dir="ltr"><<a href="mailto:Andrew.Baumann@microsoft.com">Andrew.Baumann@microsoft.com</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Zeus,<br>
<div class="im"><br>
> I made a very simple example where core 0 is sending n messages to core 1<br>
> using the UMP backend. Core 1 is just waiting and dispatching messages.<br>
><br>
> So the problem is that I can not manage to send more than 31 messages to<br>
> core 1. The message 32 is sent but core 1 doesn't receive it. The error I get is:<br>
><br>
> Failure: ( flounder) Cannot queue message for transmit: queue is full<br>
> [FLOUNDER_ERR_TX_BUSY]<br>
><br>
> In the meantime all other 31 messages have been dispatched and received<br>
> by core 1 but the sending error keeps on, so no more messages can be sent.<br>
> Message 32 seems to be on queue but never dispatched.<br>
<br>
</div>Are you processing the incoming event queue on core 0, by dispatching the waitset associated with the channel?<br>
<br>
If your program is single-threaded, then a loop like while (1) send_message(); won't work, because you also need to dispatch events on the incoming waitset in order for the UMP channel implementation to see the acks which tell it that the receiver has consumed the messages. The TX_BUSY error you're seeing is the channel implementation telling you (on core 0) that there is no space in the outgoing message queue.<br>
<br>
The correct thing to do in this case depends on your program, but assuming you want to use the single-threaded state-machine model, the right thing to do is to register a callback for the ability to send further messages (e.g. with b->register_send()), and then return to your event processing loop which should free up space in the outgoing message queue and then run your callback. You might want to have a look at the idctest program in the tree for some examples of how to use callbacks and continuations for sending.<br>
<br>
If this all sounds very painful and low-level, that's because it is :) Have you considered using a higher-level abstraction like THC?<br>
<br>
Cheers,<br>
<font color="#888888">Andrew<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Zeus Gómez Marmolejo<br>Barcelona Supercomputing Center<br>PhD student<br><a href="http://www.bsc.es" target="_blank">http://www.bsc.es</a><br><br><br>
</div>