multi-threaded apps with GTK

[mikecorn t-online de]

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.