Re: [gtk-list] Re: gdk_threads_enter is not reentrant

[Noel Burton-Krahn <noel burton-krahn com>]

Sebastian,

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.

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.

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 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?

--Noel


> Date: Tue, 14 Mar 2000 10:19:04 +0000
> From: Sebastian Wilhelmi <wilhelmi@ira.uka.de>
> 
> Hi Noel,
> 
> > Sometimes you really do need to explicitly release a mutex no matter
> > what lock depth you're at.  To do so requires you know exactly how
> > many time gdk_threads_lock has been called.  Please at least put in a
> > gdk_threads_depth counter so users can do their own lock release.
> > =
> 
> > Multithreaded programs really need to be able to do this, and it's
> > trivial to do, no matter what threads implementation you use.
> 
> No, it isn't, when I'm using the native recursive mutex implementation, a=
> s
> found in Unix98 and also linuxthreads. This native implementation is fast=
> er
> than the self-implemented one. So I don't think, we'll support that. Appe=
> nded
> is a small test-program to demonstrate the time difference:
> 
> Here are the values on my Linux machine.
> 
> Homemade: 4.086516 seconds.
> Native:   3.230480 seconds.
> 
> Bye,
> Sebastian