<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
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>> <BR><BR></body>
</html>