dataset thread savety

[Tim Janik <timj gtk org>]

hi sebastian,

in your initial thread-safety attempt at gobject, you did:

+/* Making this lock more fine grained (per pspec) doesn't seem
+ * necessary. These calls has to be protected though
+ */
+G_LOCK_DEFINE_STATIC (pspec_qdata);
+
 gpointer
 g_param_spec_get_qdata (GParamSpec *pspec,
                        GQuark      quark)
 {
+  gpointer data;
+
   g_return_val_if_fail (G_IS_PARAM_SPEC (pspec), NULL);

-  return quark ? g_datalist_id_get_data (&pspec->qdata, quark) : NULL;
+  G_LOCK (pspec_qdata);
+  data = quark ? g_datalist_id_get_data (&pspec->qdata, quark) : NULL;
+  G_UNLOCK (pspec_qdata);
+
+  return data;
 }


i don't think this makes much sense.
g_datalist_ is already guarded by the global dataset lock (and suffers
from it) for the modification functions, the only exceptionally non-guarded
functions in gdataset.c are g_datalist_id_get_data() and g_datalist_foreach().

rather than forcing users into having their own locks around these two
functions only, i think we should move to a global rw lock for datalists
that also protects g_datalist_id_get_data() and g_datalist_foreach() (for the
latter, it's probably best to walk the list one node ahead like we do
for most other foreach functions, untill we move to array storage).

for g_dataset, we can have an additional recursive mutex, that'll
take care of callback recursions while keeping modifications to a single
thread at a time, thus preserving static variable consistency. for
g_dataset, i don't consider performance too critical of an issue, so
executing user code from a recursive mutex should be fine.

---
ciaoTJ