13 Aug
2014
13 Aug
'14
6:27 p.m.
Thanks very much Daniel and Alex,
I switched to the atomic increase ("$var(x) = $shtinc(a=>x);"),
My attempt to get automatic expiration and resetting of values to 0 by
doing "modparam("htable", "htable",
"message_counters=>size=10;
autoexpire=10;initval=0;updateexpire=0;")" was not successful (values
persisted), but I could achieve it by having a timer route block (using
"rtimer") that expires every 10 second and calling
"sht_rm_name_re("message_counters=>.*");" inside it (in case that
it may
help people who will get into the same issue later)
All the best,
Alireza
On Wed, Aug 13, 2014 at 10:58 AM, Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
On 13/08/14 16:24, Alex Balashov wrote:
On 08/13/2014 10:21 AM, AliReza Khoshgoftar
Monfared wrote:
Another concern is that, if I specify a number of child processes in my
when
using hash table items in expressions.
So:
- next is an atomic increment of $sht(a=>x)
$var(x) = $shtinc(a=>x);
- but next might rise races:
$sht(a=>x) = $sht(a=>x) + 1;
because first the value is read, an add expression is evaluated and then
the item in hash table is set to new value. During the evaluation of the
expression, the current process can lose CPU, and another process can
update the item. So you can make it safer with:
sht_lock("a=>x");
$sht(a=>x) = $sht(a=>x) + 1;
sht_unlock("a=>x");
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
config (e.g. children=4), then will it be safe to
increment the hash
table entries in the route block upon receipt of messages? i.e will the
table entries that reside in the shared memory be precise? or do I need
to lock/unlock them while updating?
htable operations are thread-safe, as implemented under the hood. You do
not explicitly need to lock anything.
While that is true for htable (direct) operations, one should be careful