[prev in list] [next in list] [prev in thread] [next in thread]
List: spread-users
Subject: [Spread-users] Deadlocking occurring in multithreaded application
From: "Gregory Longo" <GLongo () olf ! com>
Date: 2007-06-28 19:29:35
Message-ID: 9A6FF2537AEA484296A3EE4990D18557044B785A () cpexchange ! olf ! com
[Download RAW message or body]
--===============1742959594==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C7B9BA.A92F8BE5"
This is a multi-part message in MIME format.
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
them.
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.
Regards,
Greg
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (filtered)">
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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. </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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 them. </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>In the function SP_scat_receive it locks the mutex associated
with the particular connection at the top:</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&Mbox_mutex[mbox & MAX_MUTEX_MASK][1]</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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. </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>I have made the changes locally, and it fixes our issues,
but I wanted to bring it to your attention. </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Regards,</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Greg</span></font></p>
</div>
</body>
</html>
_______________________________________________
Spread-users mailing list
Spread-users@lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users
--===============1742959594==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic