[SR-Users] Locking htable entries

[Daniel-Constantin Mierla]

... worth mentioning that locking for htable is re-entrant, so it is not
ending into a deadlock when doing:

 - lock slot for $sht(x=>y)

 - read/write $sht(x=>y)

 - unlock slot for $sht(x=>y)

But always do unlock if doing the lock explicitly.

Cheers,
Daniel

On 19.07.18 14:08, Daniel-Constantin Mierla wrote:
> Hello,
>
> readn and write operations are safe, done under mutex locking. So it is
> always safe to do:
>
> $sht(x=>y) = $var(y);
>
> or:
>
> $var(y) = $sht(x=>y);
>
> But there could be operations where you want that the value is not
> changed by another process while doing some operations, like: get the
> value from hash table, test it against some limit and act in different
> ways. For example, you keep active calls per user:
>
> if($sht(ac=>$fU) < 10) {
>    $sht(ac=>$fU) = $sht(ac=>$fU) + 1;
> } else {
>   sl_send_reply("403", "Too many calls");
> }
>
> From the moment you read for IF condition till the moment of increment,
> the CPU can be given to another kamailio process which does same
> operation, reading same value and at the end it gets incremented with 1
> instead with 2, obviously if the value was 9, then one call is allowed
> when it shouldn't be.
>
> So you have to protect the above example by locking the slot for
> $sht(ac=>$fU).
>
> This was a rather simple example, but hopefully clarifies when explicit
> sht lock/unlock is needed.
>
> Cheers,
> Daniel
>
> On 19.07.18 13:50, Alex Balashov wrote:
>> Hi,
>>
>> Sorry if this question has been answered before, but I'm rather puzzled
>> as to the intent behind sht_lock() / sht_unlock().
>>
>> Presumably, "thread"-safe / shm mutex locking is already implemented in
>> htable query and mutation operations, otherwise htable would be unusable in
>> a route script context. 
>>
>> So what is the purpose of this higher-level lock? Is it to create a way
>> to block config script execution in multiple processes as to serialise
>> operations? Why would one want to do this under any ordinary
>> circumstances? Perhaps it is a failure of my imagination...
>>
>> Thanks,
>>
>> -- Alex
>>

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com