[SR-Users] htable locking

[Daniel-Constantin Mierla]

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.

Cheers,
Daniel

On 07/11/14 22:19, Alex Balashov wrote:
> PS. I appear to have encountered the same deadlock problem as
> Savolainen Dmitri:
>
> http://lists.sip-router.org/pipermail/sr-dev/2014-November/026046.html
>
> On 11/07/2014 04:02 PM, Alex Balashov wrote:
>
>> The documentation for the htable module gives no guidance on whether
>> sht_lock()/unlock() should be used in all situations when writing or
>> reading from the htable. Should it be?
>>
>> I was under the impression (not supported by anything said in the
>> documentation) that read and write access to the htable is fundamentally
>> thread-safe, i.e. it is safe to both read and write to the htable even
>> if the potential exists for another worker process to do the same
>> concurrently.
>>
>> Is that not the case? If not, should there not be strong admonitions to
>> use sht_lock/sht_unlock around concurrent operations--and it sounds like
>> nearly all useful applications of the htable are essentially concurrent?
>>
>> Thanks!
>>
>
>

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