Re: [reSIProcate] Making DUM Thread-Safe
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