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