Re: GStaticMutex

[otaylor redhat com]

Umm.

Since 

 pthread_mutex_initializer_t mutex = PTHREAD_MUTEX_INITIALIZER;

Is defined to work for static initialization, and static initialization
in C is pretty strictly limited, what GLib does is quite safe.

Now, yes, its conceivable that PTHREAD_MUTEX_INITIALIZER would
contain pointers to load-resolved linker symbols. 

If we run into a platform where that is the case, we will
fix GLib on that platform. But since POSIX guarantees that mutexes
can be statically initialized, such a fix _will_ be possible.

(The reason for the configure hack is to avoid including pthread.h 
in glib.h, that and nothing more.)

And the reason that static mutex initializers are a good thing is not
because of a few calls to pthread_mutex_init() called, but because
they avoid race conditions with initializing mutexes.

Alternate methods of dealing with that are either uglier or less
portable, or both.

Feel free not to use GLib, but if you do that, please do it for
a valid reason.
 
Regards,
                                        Owen

Havoc Pennington <hp redhat com> writes:

> From: Drazen Kacar <dave srce hr>
> Subject: Re: GNOME code and ANSI C.
> To: Havoc Pennington <hp redhat com>
> Cc: Drazen Kacar <dave srce hr>, gnome-hackers nuclecu unam mx
> Date: Thu, 5 Oct 2000 04:20:38 +0200
> 
> Havoc Pennington wrote:
> > Drazen Kacar <dave srce hr> writes: 
> > > Are you aware of the fact that GStaticMutex hack is unportable and
> > > dangerous?
> > 
> > I'm not personally, I haven't looked at the implementation. I assumed
> > it would just use the usual select() trick.
> 
> It does (the g_usleep() function) and that's not the problem. But it
> locks a mutex before that. Which is also not a problem. The problem
> is the nature of the mutex.
> 
> GStaticMutex is, as its name says, a static mutex. At configure time,
> glib determines the size of the mutex structure and its contents.
> This information is stored in glibconfig.h. And then those things
> are used to initialize static mutexes (mutices?), bypassing the only
> documented way. The current 1.2.x documentation says:
> 
>    A GStaticMutex works like a GMutex, but it has one significant advantage.
>    It doesn't need to be created at run-time like a GMutex, but can be
>    defined at compile-time.
> 
> AFAIK, if you use mutex like this, standards have to say only one thing:
> "undefined behaviour." I'm not aware of a single OS which has more to
> say about it, but I'm not threads expert, so there might actually be
> some platform which has defined behaviour here. Although I doubt it.
> 
> You see, it's perfectly possible that pthread_mutex_init() on the same
> OS initializes mutex structure with the different values for single CPU,
> SMP, NUMA or COMA systems. Which is one of the reasons why mutex
> structures are opaque.
> 
> If that happens, you can throw binary compatibility down the toilet.
> If I apply a single patch for the kernel, libc or the thread library,
> nobody guarantees that the app would work any more. I'd never use hacks
> like this in my code. Since glib does, that means I can't use glib in MT apps.
> I simply don't have the balls for that. And I don't see a reason for
> using something like this in the first place. Avoiding a single call
> to pthread_mutex_init() (or equivalent) doesn't look like a compelling
> reason.
> 
> -- 
>  .-.   .-.    I don't work for my employer.
> (_  \ /  _)
>      |        dave srce hr
>      |        dave fly srk fer hr
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
> 
> ----------