[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