On Tue, Jun 26, 2012 at 12:52:07PM +0200, Marc Lehmann wrote: > On Tue, Jun 26, 2012 at 12:00:57PM +0200, Marek <[email protected]> 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 [[email protected]] _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
