How does GLib/GObject Reference Counting garbage collection system prevent race conditions in heavy-multithreaded code?

Question

I've read this great answer from @jon-harrop in Quora to the question How do reference counting and garbage collection compare? and there, it is said that one of the disadvantages of reference counting is that multithreaded reference counting is non-deterministic because increments and decrements race.

Then he goes on explaining how most of those disadvantages are solved or worked-around by some systems, giving particular examples; except in the case of this disadvantage.

So I'm wondering: does GLib/GObject's reference counting have any way to overcome this problem?

Answer 1

It uses the Atomic Operations support int GLib. On processors/compilers which support atomic operations it uses that (i.e., Atomic Builtins for GCC, InterlockedCompareExchange on Windows, etc.), and it falls back on a mutex.