Re: RE : Apparent thread-safety bug in Glib 2.0 docs

[Christopher Smith <x xman org>]

On Sun, 2003-10-26 at 01:34, Sebastian Wilhelmi wrote:
> Actually in that case everything should work OK, because the compiler
> does not know, whether g_static_mutex_lock (which is just another
> function for gcc) could indirectly access foo (e.g. by calling setFoo),
> so foo has to written to real memory before calling g_static_mutex_lock.

Well, the compiler might need some help from the linker, but
particularly if setFoo isn't an exported symbol, there are lots of ways
to be confident that the variable won't be modified. This is what global
optimizers are all about. This is particularly true if the glib library
is statically linked. As a general rule, it is dangerous to assume the
compiler and linker can't figure something out, because while it may be
true in a lot of cases, the one or two cases where they are smart enough
you'll have a terribly subtle bug.

-- 
Christopher Smith <x xman org>