2

I couldn't find any information in the glib documentation about thread safety. I guess that means I should probably assume that it's NOT thread safe, but I'm unsure about what shared resources I should be locking around.

Does anybody have any experience with thread safety using glib? What guidelines can I use to make sure my glib code is thread safe?

Thanks!

Scott Frazer
  • 2,145
  • 2
  • 23
  • 36

3 Answers3

5

Actually the glib reference manual is full of information about thread safety:

After calling g_thread_init(), GLib is completely thread safe (all global data is automatically locked), but individual data structure instances are not automatically locked for performance reasons. So, for example you must coordinate accesses to the same GHashTable from multiple threads. The two notable exceptions from this rule are GMainLoop and GAsyncQueue, which are threadsafe and need no further application-level locking to be accessed from multiple threads.

You might want to take a look at threads section of the reference manual.

drakide
  • 1,757
  • 2
  • 15
  • 23
0

Global policy is simple: all are threadsafe with exception of data manipulation funcs. Read there: http://developer.gnome.org/glib/stable/glib-programming.html

DenisKolodin
  • 13,501
  • 3
  • 62
  • 65
0

From the GLib reference manual you can get the following statement:

GLib itself is internally completely thread-safe (all global data is automatically locked), but individual data structure instances are not automatically locked for performance reasons.

So to complement the previous answers, you don't need to call g_thread_init().

Mazze
  • 1,354
  • 4
  • 17
  • 35