19 Jul
2018
19 Jul
'18
2:08 p.m.
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