Hi benny, I've read the wiki and found it very interesting. I just didn't understand if I need to follow the order suggested there if I lock a mutex that doesn't do anything with a call object. For example when creating a timer. I my application I create a timer and update a variable indicating that the timer is active. So if I create the timer from two different threads at the same time I need a mutex or I will be writing to this variable from two threads and the application crashes. For example: I could create a timer from a dtmf trigger (media thread) and from a wav eof (clock thread). In my code I am only locking the mutex that I created to control the access to the timer variable in my application. I have a similar situation with a database connection thats can only have one thread accessing it. And if I don't need to lock PJSUA for this cases, how do I know when I will have to really call acquire_call()? Thanks for all help, Thiago > > > seem to hold the PJSUA lock. I suspect they might also hold a > dialog lock? > > > > > > > Yes they do. And it's mandatory that locks must be acquired in > uniform > > order, or otherwise we'll have deadlocks. I was pretty confident > that > > such an important issue must have been documented somewhere, but > turns > > out there's none of this. So for now, the only information about > this > > is here: http://trac.pjsip.org/repos/changeset/729. I'll work on > a > > wiki shortly. > > Please find the (new) wiki here: > http://trac.pjsip.org/repos/wiki/PJSUA_Locks > > cheers, > -benny Abra sua conta no Yahoo! Mail, o ?nico sem limite de espa?o para armazenamento! http://br.mail.yahoo.com/
