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
Unintended Recipient & Unauthorized Use of E-Mail:
This message and attachments may contain confidential or privileged
information that is intended only for the named recipient of this
e-mail. Any unauthorized use or distribution is not permitted. If you
have received this e-mail in error, deleting the e-mail and notifying
the sender would be appreciated. Thank you.
