[Spread-users] Deadlocking occurring in multithreaded application with multiple spread sessions.

Gregory Longo GLongo at olf.com
Thu Jun 28 15:29:35 EDT 2007

In testing the use of spread in our Open Link application I have found
several situations that can result in deadlocks, when using spread in a
multi-threaded application.  


We have a main thread in our application that connects/disconnects from
spread for every one of our "internal sessions".  Each "internal
session" has a separate thread to receive the messages from spread and
queue them up internally.  I have been testing situations where we
create multiple "internal sessions" of our application and then remove


In the function SP_scat_receive it locks the mutex associated with the
particular connection at the top:


&Mbox_mutex[mbox & MAX_MUTEX_MASK][1]


However, there are several situations where it returns without unlocking
that mutex.  Most or all of them seem to be the case are when the
spread session is taken out from underneath it by a seperate thread (as
is happening in our application).  However, since the mbox is mapped to
a mutex from 1 - 255,  different spread mboxes can share the same mutex.
This results in a deadlock with the other thread mapped to the same
mutex is stuck waiting for the thread that already returned, to give up
the lock on its mutex.


Although I didn't run into it, a similar situation seems like it can
occur in SP_internal_multicast where the mutex (&Mbox_mutex[mbox &
MAX_MUTEX_MASK][0]) is not always unlocked. 


I have made the changes locally, and it fixes our issues, but I wanted
to bring it to your attention.  




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.spread.org/pipermail/spread-users/attachments/20070628/43568fd1/attachment.html 

More information about the Spread-users mailing list