The following functions use g_array_index():

  gst_value_can_union()
  gst_value_union()
  gst_value_can_intersect()
  gst_value_intersect()
  gst_value_subtract()

while the following functions use g_array_append()

  gst_value_register_union_func()
  gst_value_register_intersect_func()
  gst_value_register_subtract_func()

all accessing arrays with file scope unprotected by mutexes. 

gst_value_register_foo_func() might trigger a g_realloc() within GLib; if at the
same time a gst_value_foo() operation is going on in another thread, the memory
it accesses from g_array_index() has become invalid and bad things will happen.

This is a bit of a theoretical problem, but IMHO we should either make things
thread-safe or document the thread unsafety of these functions.

Of course this is not a problem for GStreamer itself. In GStreamer, all GstValue
stuff is registered from gst_init(), and at that point we don't need to worry
about thread-safety yet.

However, the GstValue API is public, and any application or plugin or library
built on top of GStreamer is free to use it, and there is AFAICS no way to
guarantee for these users that they can register their stuff in a context where
thread-safety is not an issue (e.g. in case of a plugin loaded later).

Locking might be undesirable for performance reasons in functions like these,
but given the context they are usually used from (gst_caps_*) I find it hard to
believe that the performance impact of locking is actually significant here
(pure guesswork of course).