Hello,
your log message saying that the lock is released is printed after
unlock(). When unlock() is executed, the process can lose the CPU and
the other process enters the lock() and does its stuff, can even
overtake the first process and printing that it released the lock,
nothing is guaranteed outside of lock()/unlock(), it is OS scheduler
deciding what to do.
Cheers,
Daniel
On 03.07.17 12:12, Sebastian Damm wrote:
Hi Daniel,
thanks for the reply.
On Mon, Jul 3, 2017 at 11:57 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
the last log message is outside of the
lock()/unlock(), so it can
printed whenever the OS decides to allocate CPU for it. You should move
it inside the locked block, but then also be sure the syslog is not
asynchronous, because then it can be syslog changing the order.
Well but
shouldn't it be printed only after the lua block was
executed? It still looks like the second packet didn't wait for the
first packet to release the lock.
My problem is, that I'm writing entries into a hash table if some
conditions of an INVITE matches. But the 100 Trying often comes in
before the processing of the INVITE is finished. So it is dropped
because the reference in the hash table is missing. That's why I
wanted to have locking. The second process shouldn't print out
"Obtained lock" until the other one has released the lock. And since
the first process is still within it's lua logic, I'm pretty sure the
lock has not been released.
Also, unrelated, you should not use drop, unless
you want to drop the
response and not sending it out. For request is not making any
difference compared with exit.
Actually, I want to drop every packet on the
system, because it is
only a sniffer that does something with the sniffed packets.
Best Regards,
Sebastian
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users