Reputation: 2185
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!
Upvotes: 2
Views: 3800
Reputation: 1404
From the GLib threads documentation 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()
.
Upvotes: 1
Reputation: 15081
Global policy is simple: all are threadsafe with exception of data manipulation funcs. Read there: GLib – 2.0: Writing GLib Applications
Upvotes: 1
Reputation: 1757
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.
Upvotes: 5