GStaticMutex

[Havoc Pennington <hp redhat com>]

--- Begin Message ---

• From: Drazen Kacar <dave srce hr>
• To: Havoc Pennington <hp redhat com>
• Cc: Drazen Kacar <dave srce hr>, gnome-hackers nuclecu unam mx
• Subject: Re: GNOME code and ANSI C.
• 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

--- End Message ---