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!