tree e2b3fb9252c0f5a7d5292357fda95bf8116480b3
parent 7cb8a08c84438d6646f33496d82bb9d7ff1309fa
author Simon McVittie <simon.mcvittie@collabora.co.uk> 1307725691 +0000
committer Jaikumar Ganesh <jaikumar@google.com> 1322785933 -0800

Consistently use atomic operations for all access to DBusConnection refcount

Trying to mix atomic operations with locked non-atomic operations is
broken: the atomic ops aren't necessarily atomic with respect to the
locked non-atomic ops, and the non-atomic ops aren't protected by the
lock because the atomic ops can change the refcount behind their back.

In theory we could use the connection lock if atomic ops aren't supported
(making a per-connection lock cheaper than the global lock used to
implement atomic ops) *and* our mutexes are recursive (making it safe
against deadlocks)... but life's too short.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38005
Tested-by: Will Manley <freedesktop williammanley net>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>