Re: thread-safety of counters

W dniu 23.02.2015 o 21:06, Thiago Macieira pisze:
> dbus_message_cache_or_finalize implies that the reference count has dropped to 
> zero, which means there's no concurrency issue any more.

That's right, reference count for the _message_ is zero. But reference
count for a counter (the one from message->counters) is non-zero. In
fact, it should be at least 1 for the whole lifetime of
connection->transport. The problem is, that it drops to zero due to
non-atomic reference count, and is freed, while connection->transport is
still alive.

> In turn, this means the following call stack cannot be concurrent:
> 
>> Call stack for ref is:
>> _dbus_counter_ref
>> _dbus_message_add_counter

This is for another message. In another thread. I copied these call
stacks from the actual gdb session in a single, specific moment:
(gdb) info threads
  Id   Target Id         Frame
  11   Thread 0xb4fdd460 (LWP 3073) "tt" _dbus_counter_unref
(counter=0x117d8) at dbus-resources.c:128
  10   Thread 0xb51dd460 (LWP 3072) "tt" (running)
  9    Thread 0xb53dd460 (LWP 3071) "tt" (running)
  8    Thread 0xb55dd460 (LWP 3070) "tt" (running)
  7    Thread 0xb57dd460 (LWP 3069) "tt" (running)
  6    Thread 0xb59dd460 (LWP 3068) "tt" (running)
* 5    Thread 0xb5bdd460 (LWP 3067) "tt" _dbus_counter_ref
(counter=counter@entry=0x117d8) at dbus-resources.c:112
  4    Thread 0xb5ddd460 (LWP 3066) "tt" (running)
  3    Thread 0xb5fdd460 (LWP 3065) "tt" (running)
  2    Thread 0xb61dd460 (LWP 3064) "tt" (running)
  1    Thread 0xb63de000 (LWP 3061) "tt" (running)

>> 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.

In my opinion, that should be changed if libdbus is meant to be thread-safe.

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