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!
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!
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!
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().
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.
Cheers, Daniel
On 10 Nov 2014, at 10:26, Daniel-Constantin Mierla miconda@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.
/O
On 10/11/14 10:28, Olle E. Johansson wrote:
On 10 Nov 2014, at 10:26, Daniel-Constantin Mierla miconda@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
-
Alex Balashov -
Daniel-Constantin Mierla -
Olle E. Johansson