[SR-Users] htable locking

Daniel-Constantin Mierla miconda at gmail.com
Mon Nov 10 10:40:16 CET 2014


On 10/11/14 10:28, Olle E. Johansson wrote:
> On 10 Nov 2014, at 10:26, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>
>> On 07/11/14 22:54, Alex Balashov wrote:
>>> On 11/07/2014 04:45 PM, Daniel-Constantin Mierla wrote:
>>>> Using sht_lock() and accessing an item on the same slot is ending up in
>>>> a deadlock.
>>>>
>>>> Should be avoided for the moment -- I didn't have time to look for a
>>>> solution with the work on releases during the past days.
>>>>
>>>> The share hash table is available to all processing, the access to items
>>>> is synchronized. So if two processes need to access exactly the same
>>>> item, then one waits for the other. However, accessing the same item at
>>>> the same time is not that common, as each worker handles different
>>>> traffic, but it is a possibility.
>>> It is indeed a possibility if one is using it to store global
>>> variables, as it is the only "kind of nonscalar" structure available
>>> for that purpose besides the very primitive global $shv().
>>>
>> For the records, the master branch has a patch for allowing re-entrant
>> locking of the slot from same process, so the issue should be fixed.
> I suggest that we treat this as a bug and backport to 4.2 when it's confirmed to solve the issue.
Yes, it will be backported to get the sht_lock() working safe. Not sure
if for 4.2.1, unless we get many people testing it properly, but for
4.2.2 should be ok.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com




More information about the sr-users mailing list