thread-safety of counters
Adrian Szyndela
adrian.s at samsung.com
Tue Feb 24 00:50:59 PST 2015
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 at 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.
More information about the dbus
mailing list