And, as I found out the hard way, you need to be very careful when calling PJ functions that will lock things you may not know about. This gets trick with callbacks, since they have already locked things, so locking an app-lock poses issues (e.g. your DB lock, though you probably shouldn't be calling DB functions from a callback.) A main thread function would want to lock the app lock, but when it calls various PJ functions, it can deadlock with your callback. I sort of get around this by trying to not call any PK functions if I have an app lock. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Feb 13, 2008, at 11:09 AM, Michael Broughton wrote: > tloginbr-pjsip at yahoo.com.br wrote: >> 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 >> >> > 1. dialog > 2. ua > 3. pjsua > 4. application > > You don't actually have to lock every single lock in the list, as > long as you always respect the locking order. > > In the case of you database connection, you are probably doing > something like this: > > serial_db_operation(): > lock_db() > db_operation() > unlock_db() > > The database lock is implicitely added to the above list in > position 5. This operation should be safe to call at any time. > > > > -- > Michael Broughton, Advanis > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080213/f9727aa8/attachment.html
