Re: multi-threaded apps with GTK

[Chris Vine]

On Thursday 09 February 2006 20:56, [EMAIL PROTECTED] wrote:
> I am now making good progress, thanks to the advice I got in this forum.
> Many thanks to all those who chipped in, even though I got emotional
> from my frustrations.
>
> I complained 1-2 weeks ago that GTK does not work out of the box for
> multi-threaded apps, and asked, why not? A complex and poorly documented
> burden is placed on the programmer using GTK, IMO.
>
> One of the answers I got was that the overhead of locking shared
> resorces should not be borne by apps that do not need this. I responded
> that locking takes nanoseconds (as long as the resource is not already
> locked from another thread). Someone asked me if I knew what I was
> talking about. Today I took the time to write a benchmark. I am not sure
> this is the right benchmark for this issue, but here are the results.

The main problem is not overhead, but with having hidden global locking in GUI 
toolkits in the first place.  This very easily results in deadlocks from 
out-of-order locking with other mutexes employed by the user.

Qt adopts exactly the same approach as GTK+.  Events either have to be posted 
as messages to the event loop thread from other threads, or if window system 
functions are invoked directly from a thread other than the Qt event loop 
thread, then the global Qt lock must be explicitly invoked by the user (and 
the user is accordingly responsible for avoiding deadlocks, which is 
something you did not manage).

When I last looked at it, Windows only allows the posting of events and no 
direct invocation of window functions from multiple threads.

Glib has GAsyncQueue for message passing between threads.  Other approaches 
often used are to pass events by using a GIOChannel object (or some other 
GSource object) and a pipe, which is more closely analogous to the Windows 
and Qt approaches.  For an example of this see

http://cvs.sourceforge.net/viewcvs.py/efax-gtk/efax-gtk/src/utils/notifier.h?rev=1.10
and
http://cvs.sourceforge.net/viewcvs.py/efax-gtk/efax-gtk/src/utils/notifier.cpp?rev=1.8

The "burden on the programmer" is not "poorly documented" - the FAQ on this 
was given to you earlier and the example given is very similar to the example 
given, for example, in the Qt documentation pages.  And it is no more complex 
than it has to be, or than other comparable toolkits are.

Chris

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

multi-threaded apps with GTK

[mikecorn]

I am now making good progress, thanks to the advice I got in this forum. 
Many thanks to all those who chipped in, even though I got emotional 
from my frustrations.


I complained 1-2 weeks ago that GTK does not work out of the box for 
multi-threaded apps, and asked, why not? A complex and poorly documented 
burden is placed on the programmer using GTK, IMO.


One of the answers I got was that the overhead of locking shared 
resorces should not be borne by apps that do not need this. I responded 
that locking takes nanoseconds (as long as the resource is not already 
locked from another thread). Someone asked me if I knew what I was 
talking about. Today I took the time to write a benchmark. I am not sure 
this is the right benchmark for this issue, but here are the results.


Benchmark: 1-9 threads all do the following:

  while (elapsed_time < 5 seconds)
 lock a mutex with pthread_mutex_lock()
 increment a counter
 unlock the mutex with pthread_mutex_unlock()

All threads contend for the same mutex. Only one at a time will be able 
to increment the counter. The counter reveals how fast the lock/unlock 
and thread switching is happening.


Results using Linux kernel 2.6.15 uniprocessor: 27 million per second, 
shared among the 1-9 threads running. e.g. 1 thread iterates 27 million 
per second, 9 contending threads average about 3 million each.


Using the same kernel, SMP version, and an AMD64X2 CPU (dual core), the 
performance is strange. 1 thread gets the same 27 million, but multiple 
threads cause the total to sink to 7 million. Evidently Linux has a 
problem with SMP, or with AMD. 7 million per second is not exactly slow.



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list