Calling ev_async_send() from multiple threads.

[Marek Denis]

On Tue, Jun 26, 2012 at 12:52:07PM +0200, Marc Lehmann wrote:
> On Tue, Jun 26, 2012 at 12:00:57PM +0200, Marek <marek at octogan.net> wrote:
> > Here is that A_cb():
> > 
> > mutex.lock()
> >   while(!queue.empty()) {
> >     data = get_data_from_hared_queue();
> >     flow->B_notify(data);
> >   }
> > mutex.unlock();
> > 
> > 
> > and B_notify(data) will look like:
> > 
> > appropriate_queue = choose_queue_from_object();
> > appropriate_queue.add(data);
> > this->async_watcher.send(); (let's imagine it runs iterate_cb()
> > function)
> 
> I assume there is some pthread_mutex_lock/unlock inside
> appropriate_queue.add.
> 
> Then it looks fine to me.

Basically I operate within a "main thread" and some tasks are done 
within separated threads (they may last e.g. couple of minutes or even 
hours). However, I need to pass the "result" from the helper thread to the main one by using shared queue. 
Fetching the result is done in A_cb() callback and locking 
is justified there [I also assume that even though the async watcher is 
triggered from the "helper thread context", the callback will be 
launched within the main thread]. However, next steps, like B_notify() 
will work on objects/queues modified only within one (main) thread, so 
no locking is required here.

> I don't really know what iterate_cb is supposed to be, but ev_async_send
> is pretty simple and can be called at any time.
> 
> It would probably be most efficient to call it outside your lock (as in
> Your example), but you can also call it inside your lock.

I don't really like that kind of debugging, but did simple "printf() 
debugging" and indeed, I first ended e.g. B_notify() function and started 
running iterate_cb() function which is an expected behaviour.


Anyway, thanks for your help and clarification!

-- 
Marek Denis 
[marek at octogan.net]