[SR-Users] Locking htable entries

Daniel-Constantin Mierla miconda at gmail.com
Thu Jul 19 14:08:52 CEST 2018


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




More information about the sr-users mailing list