Re: thread-safety of counters

On Monday 23 February 2015 16:38:44 Adrian Szyndela wrote:
> Call stack for unref is:
> _dbus_counter_unref
> dbus_message_cache_or_finalize
> dbus_message_unref
> <client; fun() in sample program>

dbus_message_cache_or_finalize implies that the reference count has dropped to 
zero, which means there's no concurrency issue any more.

In turn, this means the following call stack cannot be concurrent:

> Call stack for ref is:
> _dbus_counter_ref
> _dbus_message_add_counter
> _dbus_transport_queue_messages
> < ... transport functions ... >
> _dbus_transport_do_iteration
> _dbus_connection_do_iteration_unlocked
> _dbus_connection_block_pending_call
> dbus_pending_call_block
> dbus_connection_send_with_reply_and_block
> <client; fun() in sample program>

The above access should be protected by mutexes, while the one before isn't 
(it was protected by a refcount).

> The rer/unref functions on an ARM are compiled to:
> Dump of assembler code for function _dbus_counter_ref:

Those are not meant to be atomic.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus