7 Nov
2014
7 Nov
'14
10:45 p.m.
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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com
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!