[gst-devel] Possible race-condition when using g_enum_register_static

[Tim Müller]

On Wed, 2007-10-17 at 20:32 +0200, Michal Benes wrote:

> gst_mad_emphasis_get_type (void)
> {
>   static GType mad_emphasis_type = 0;
>
>   if (!mad_emphasis_type)
>     mad_emphasis_type = g_enum_register_static ("GstFooBar", ...)
>
>   return mad_emphasis_type;
> }
> 
> Isn't this racy when two mad plugins in two separate threads call this
> function for the first time? They clearly share the mad_emphasis_type
> variable. 

This is indeed racy.


> The problem is that the code like this is quite common in GStreamer.
> Am I wrong or is this a real problem?

I am not sure whether this really is a problem in practice, since these
_get_type() functions will first be called from within the plugin_init
function when the plugin is loaded and the element is registered [*],
and the plugin loading is serialised.

But then you've seen those warnings, so I must be missing something.

Patches to port these enum constructs to GOnce would be great in any
case, I think (see the glib-mkenums generated gstenumtypes.c).

What has been a problem in the past are things like custom GstBuffer
subclasses, which are usually only instantiated from streaming threads.
For those one has to do an explicit _class_ref() in the plugin_init
function to work around raciness in the type function and raciness in
GObject (when creating the class).

Cheers
 -Tim


[*] gst_element_register() will do a g_type_class_ref() on the element's
GType, which will lead to the class_init function being called, which
will lead to the enum types being registered when the class_init
function registers the enum properties.