Re: gdk_threads_enter is not reentrant
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: gtk-list redhat com, Gtk Development List <gtk-devel-list redhat com>
- Subject: Re: gdk_threads_enter is not reentrant
- Date: Wed, 15 Mar 2000 14:05:47 +0100
[This is some kind of followup to my last mail: "Changes to the mutex code." ]
> 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
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.
Sebastian Wilhelmi | här ovanför alla molnen
mailto:email@example.com | är himmlen så förunderligt blå
] [Thread Prev