Re: glib: processing events in multiple threads



On Tue, 2013-04-30 at 13:26 +0200, richard boaz wrote:

        To be more specific: what I wanted to avoid was the need to protect data
        with mutices by ensuring that the only code ever touching it is from the
        same thread. That is easier to enforce than correct mutex locking.


this, of course, comes down to your requirements' details.

Exactly. In my case (and I suspect also in many other simple GUI apps)
there is no data parallelism, it's all about glueing together blocking
method calls while preserving some kind of responsiveness to additional
events. It's not nice, but writing from scratch is not attractive
either.

  only one recommendation here: when using mutexes, make sure that you
surround absolutely the fewest number of lines possible to guarantee
single access.

I have written multithreaded code for over 20 years; trust me, I know
the pitfalls.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]