<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>+1 on this. Likely far more mileage from cleanups like this
than in refactoring to use lockless lists.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Mike<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de] <b>On Behalf Of </b>Stefan
Andersson<br>
<b>Sent:</b> Monday, December 01, 2008 7:56 AM<br>
<b>To:</b> opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] Lockless Lists?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>I have a nagging feeling that we have quite
a few constructs like this<br>
<br>
A -> B -> C -> D <br>
<br>
where A locks on a mutex, then calls B that looks innocuous enough, but
that in turn sometimes calls C that calls the long running/context
switching D function.<br>
<br>
Ususally, it's a bad idea to call foreign classes in a
lock-block. Usually, it's quite easy to refactor blocks that do into
blocks that don't.<br>
<br>
And, I know that at least historically, I've seen constructs that lock in order
to serialize calls, rather than to protect data. (Hello,
OpenSim.Data)<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
Join the 3d web revolution : <a href="http://tribalnet.se/">http://tribalnet.se/</a><br>
<br>
<br>
<br>
<br>
<br>
> Date: Mon, 1 Dec 2008 08:32:40 -0500<br>
> From: sdague@gmail.com<br>
> To: opensim-dev@lists.berlios.de<br>
> Subject: Re: [Opensim-dev] Lockless Lists?<br>
> <br>
> Justin Clark-Casey wrote:<br>
> > Frisby, Adam wrote:<br>
> >> I’ve managed to get the majority of my goals solved here without <br>
> >> removing the locks – but by making a new EntityManager to deal
with <br>
> >> those locks.<br>
> >><br>
> >> <br>
> >><br>
> >> Code has been checked in tonight as it doesn’t look like it
should cause <br>
> >> any new issues. May improve performance during login/logout – but
<br>
> >> ScenePresences (which I haven’t touched yet) is probably the real
<br>
> >> culprit there.<br>
> > <br>
> > To be honest, I suspect the real issue on login/logout performance is
the fact that mono does not yet implement thread <br>
> > prioritization - you can see it but properties such as
Thread.Priority are merely stubs.<br>
> > <br>
> > So when a login/logout comes along it's not currently possible to
give existing clients or threads such as the scene <br>
> > update execution priority. So I'm thinking that the significant cpu
spike on login/logout slows the whole system down.<br>
> > <br>
> > I looked at login recently and I don't believe that the periods of
lock holding are significant enough to be causing the <br>
> > delay.<br>
> > <br>
> > No actual proper performance analysis was carried out so I could be
wrong.<br>
> <br>
> Using serverstats, something I've noticed is that on Linux after you get<br>
> a dozen people into your environment, system time of the process ends up<br>
> matching user time of the process (about 7% of total CPU for both).<br>
> This lines up with when the lag starts to get bad.<br>
> <br>
> High system time on linux means there is something the kernel is doing<br>
> for you that you need to watch for. Typically this includes locking.<br>
> <br>
> So I tend to believe the locking is really the problem. Also, the china<br>
> team got their 1000 avatars simulated on OpenSim by doing lots of lock<br>
> removal. That work was over a year ago, but I suspect the approaches<br>
> are still valid.<br>
> <br>
> I do think this is where our biggest choke point is right now. One<br>
> question I've got is whether the synchronized datastructures on mono are<br>
> more efficient than doing the locks yourself. On .NET that is known to<br>
> be true, but I'm not sure on Mono. I integrated one such change in the<br>
> packet outgoing queue 6 months ago, and got some confirmation that<br>
> stability went up after that change.<br>
> <br>
> -Sean<br>
> <br>
> -- <br>
> Sean Dague / Neas Bade<br>
> sdague@gmail.com<br>
> http://dague.net<br>
> <br>
> <o:p></o:p></span></p>
</div>
</body>
</html>