Re: [reSIProcate] Making DUM Thread-Safe
It's more than just providing mutexing on the DialogUsageManager
methods - you need to protect every DUM method call (ie.
InviteSession, ClientRegistration, ClientSubscription, etc.).
Providing this mutexing in the DUM project itself that will be
efficient for all users, is not really achievable. Some DUM methods
may be called from your callbacks (which would already be mutexed from
the process loop), and others from an application thread (which would
require mutexing). If you want to go the mutexing route, I still
think its best if you just provide the mutexing in your application,
wherever it is needed.
I think the best generic thread safe solution is the DumCommand
approach. Some InviteSession methods have already been converted to
do this - see InviteSession::xxxxCommand (ie.
InviteSession::provideOfferCommand) for an example. There are
definitely complications with this approach as well - especially for
any methods that return data.
Scott
On Tue, Jul 22, 2008 at 2:07 PM, Matthias Moetje <moetje@xxxxxxxxxxxx> wrote:
> Hi Scott,
>
> thanks a lot for your reply!
>
> Creating and posting DumCommand subclasses for all
> actions I want to take (like described in the wiki)
> seems too much overhead and makes things just more
> complicated. I don't even think this would work
> in all cases since many dum classes are calling
> DialogUsageManager::Send under the hood and I wouldn't
> know how to override all that. Thus, the mutex
> solution seems much more appealing..
>
> Would there be any objections to making the relevant
> DialogUsageManager functions virtual (in the main branch)?
>
> To me it seems that subclassing DialogUsageManager and
> DumThread would involve the least amount of code changes.
> Adding two classes "DialogUsageManagerSafe" and "DumThreadSafe"
> might (still to be analyzed further) be sufficient and
> other users could benefit from it.
>
> Any opinions on this?
>
> Best regards,
>
> Matthias Moetje
> ______________________________________________
>
> TERASENS GmbH Phone: +49.89.143370-0
> Augustenstraße 24 Fax: +49.89.143370-22
> 80333 Munich e-mail: info@xxxxxxxxxxxx
> GERMANY Web: www.terasens.com
> ______________________________________________
>
>
>
>> -----Original Message-----
>> From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
>> Sent: Montag, 21. Juli 2008 15:05
>> To: Matthias Moetje; resiprocate-devel@xxxxxxxxxxxxxxx
>> Subject: Re: [reSIProcate] Making DUM Thread-Safe
>>
>> ...
>>
>> On Sat, Jul 19, 2008 at 6:28 PM, Matthias Moetje <moetje@xxxxxxxxxxxx> wrote:
>> > Hi,
>> >
>> >
>> >
>> > although our application calls dum functions from multiple threads we
>> > haven't run into any problems yet (I don't know why) apart from some
>> > crashes
>> > when shutting down...
>> >
>> >
>> >
>> > Nevertheless I want to get I want to get rid of any possible concurrency
>> > problems. The results of my recent assessments are:
>> >
>> >
>> >
>> > · dum callbacks into my application are not an issue since it is
>> > already well protected
>> >
>> > · Many dum functions do not need any modifications because no
>> > common
>> > resources are used (e.g. MakeResponse, makeRegistration, makeNewSession
>> > etc.)
>>
>> Right - but then you must call the DialogUsageManager::send method,
>> and this must be thread safe.
>>
>> > · Some dum functions pass messages directly to the stack. No
>> > modification is needed because the communication between dum and the stack
>> > is already thread safe
>> >
>> > · Some DialogUseManager functions need a mutex to avoid concurrent
>> > access
>>
>> [Scott] If you want to call them multiple threads, then that's
>> correct. However you would be better off doing the mutexing outside
>> of DUM, in your application, so that you don't need to have a fork of
>> the resip code. Otherwise you could do all DUM work from a singe
>> thread by queuing events to the process loop thread. See recon for an
>> example of how to do this.
>>
>> > · The DumThread class's Thread() function would need to be modified
>> > to use this mutex
>>
>> [Scott] Yes - if you want to call DUM methods from multiple threads
>> then you must also mutex the process() method.
>>
>> >
>> > So my questions are:
>> >
>> >
>> >
>> > Are these assessments correct?
>> >
>> > Which are the DialogUseManager functions that need to be modified?
>> >
>> > Would it be sufficient to make modifications to DialogUseManager functions
>> > or would other classes need modification, too?
>>
>> [Scott] It would be safer to just assume that all DUM methods you
>> call must either be Mutex'd or called from the same thread.
>>
>> > Would there be a general interest to have these things integrated into dum
>> > (single-threaded apps wouldn't be affected anyway)?
>> >
>> > Or would it be better to create a layer above dum (class inherited from
>> > dum), would that be possible at all?
>>
>> [Scott] I think it's best to layer above DUM. The methods you would
>> need to override are not currently virtual so you cannot inherit from
>> DialogUsageManager. Your best bet would be to write your own wrapper
>> for the DUM API calls you need, and write your own version of
>> DumThread, if you plan to go the Mutex route.
>>
>> Note: some of this info is also here:
>> http://www.resiprocate.org/DUM_Threading
>>
>> Scott
>