Re: gdk_threads_enter is not reentrant

[Sebastian Wilhelmi <wilhelmi ira uka de>]

[This is some kind of followup to my last mail: "Changes to the mutex code." ]

Hi Noel,

> Yes, I see that your native threads run 0.85 seconds faster in
> 8,000,000 calls.  That is a very tiny difference (1.0e-07 sec/call),
> but that's beside the point.

It's 20% faster for a thing, that is called OFTEN.

> I think that using native recursive threads is a good idea.  But you
> really do need a depth counter too.  There are times when you have to
> be sure that you release a mutex completely to avoid deadlock.  If the
> mutex is recursive, a single release won't do.  You need to know how
> many times a mutex has been locked to be able to release it
> completely.

Having both (that is a recursive mutex, that can be fully released) seems like
a good idea, but it really makes the interface bloated, it exposes the depth
and makes things slower for all, without making it much better. I really am
not sure, what to do. On one hand I agree with you, on the other hand I relly
would like to have a lean and fast mutex in GLib. One solution might be to add
a dedicated recursive mutex, that doesn't work with the g_mutex_lock etc.
functions. But that's actually the way, it now is in GLib 1.3. Than we only
would have to change the code in GTK+ to use that. I'll have a look. 

Yes, I think I'll change my patch to make you and the other GTK+ users happy.

So please, everyone, disregard my last mail regarding the mutex change. I'll
sit down and do it another way, leaving the native mutex untouched. 
 
> It sounds like you've never encountered this problem.  How do you
> avoid it in your own multithreaded programs?  If you don't write many
> multithreaded programs, then please take my advice: this feature
> really is necessary in some situations.

I'm very seldom writing multithreaded GUI-programs, but when I wrote the
MT-extension to ORBit, I was quite happy with normal mutexes.

> I am tired of kludging around the current GDK threads implementation.
> That's why I'm pushing for a complete solution in the next version.
> What's the point of speed (especially a gain of less than 1
> microsecond per call) at the expense of functionality?

I would argue, that most people are quite content with the way, things are
done now. You have to consider, how often a mutex is locked, and that those
microseconds tend to pile up. Of course I know, that premature optimization is
the root of all evil, as Knuth nicely put it, but in that case it seems rather
obvious to be a hot spot.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |     är himmlen så förunderligt blå
http://goethe.ira.uka.de/~wilhelmi   |