Re: Is GLIB thread safe?

[Paul Davis <paul linuxaudiosystems com>]

On Sun, 2008-10-26 at 00:25 +0800, Peter Cai wrote:
> Hi all,
> 
> I'm writing a COM program on windows but I'm not quite familiar with C++.
> thus I decided to use mostly C instead and I want to use GLIB in it.
> 
> But I got one problem.  Is GLIB thread safe?

generally speaking no.

let me give you some background. glib was originally developed on POSIX
conformant platforms in which process creation is cheap and it has been
more common for people to use fork() than multiple threads. it is
traditional in these environments to not burden library code with
mutexes and other sync-related primitives because the common case is
generally non-threaded. applications that are multithreaded get to do
their own explicit locking, without causing overhead for the common
case. there are many other examples of this, the most prominent being X
Window. 

win32 has traditionally been more or less the opposite: process creation
is expensive, and apps tend to be multithreaded rather than using
fork(). as a result, library code tends to includes mutexes etc. so that
the common case (multithreaded code) works, even though its costs
uni-threaded code quite a lot in performance terms.

which one is right? it hardly matters. glib doesn't use implicit mutexes
etc. to provide thread safety - that is up to your app. 

the thread init calls are there because there are (internal) parts of
glib that your app cannot protect itself. if compiled and used
appropriately, glib will ensure that these are also thread-safe.

--p