[sr-dev] The recursive lock of tm module is not safe?
Richard Fuchs
rfuchs at sipwise.com
Thu Apr 14 14:17:48 CEST 2022
On 13/04/2022 06.56, [EXT] 王斌 wrote:
>
> Hi:
>
> See lock_hash in h_table.c:
>
> Flowing lines of code do not guarantee atomicity and I think it is not
> safe:
>
> -atomic_get(&_tm_table->entries[i].locker_pid) != mypid
>
> -lock(&_tm_table->entries[i].mutex)
>
> -atomic_set(&_tm_table->entries[i].locker_pid, mypid)
>
Not my code, but I would say it is safe, because the only race condition
you could possibly encounter where it would make a difference is when
atomic_get(&locker_pid) returns a value other than mypid (true
condition) and is then subsequently set to mypid by a different thread
before the mutex can be acquired (flipping the condition to false),
which cannot happen because all threads have different PIDs.
Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20220414/4d3c13ec/attachment.htm>
More information about the sr-dev
mailing list