[Opensim-dev] Lockless Lists?

[Stefan Andersson]

I have a nagging feeling that we have quite a few constructs like this
 
A -> B -> C -> D 
 
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.
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.
 
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) Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ > Date: Mon, 1 Dec 2008 08:32:40 -0500> From: sdague at gmail.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Lockless Lists?> > Justin Clark-Casey wrote:> > Frisby, Adam wrote:> >> I’ve managed to get the majority of my goals solved here without > >> removing the locks – but by making a new EntityManager to deal with > >> those locks.> >>> >> > >>> >> Code has been checked in tonight as it doesn’t look like it should cause > >> any new issues. May improve performance during login/logout – but > >> ScenePresences (which I haven’t touched yet) is probably the real > >> culprit there.> > > > To be honest, I suspect the real issue on login/logout performance is the fact that mono does not yet implement thread > > prioritization - you can see it but properties such as Thread.Priority are merely stubs.> > > > So when a login/logout comes along it's not currently possible to give existing clients or threads such as the scene > > update execution priority. So I'm thinking that the significant cpu spike on login/logout slows the whole system down.> > > > I looked at login recently and I don't believe that the periods of lock holding are significant enough to be causing the > > delay.> > > > No actual proper performance analysis was carried out so I could be wrong.> > Using serverstats, something I've noticed is that on Linux after you get> a dozen people into your environment, system time of the process ends up> matching user time of the process (about 7% of total CPU for both).> This lines up with when the lag starts to get bad.> > High system time on linux means there is something the kernel is doing> for you that you need to watch for. Typically this includes locking.> > So I tend to believe the locking is really the problem. Also, the china> team got their 1000 avatars simulated on OpenSim by doing lots of lock> removal. That work was over a year ago, but I suspect the approaches> are still valid.> > I do think this is where our biggest choke point is right now. One> question I've got is whether the synchronized datastructures on mono are> more efficient than doing the locks yourself. On .NET that is known to> be true, but I'm not sure on Mono. I integrated one such change in the> packet outgoing queue 6 months ago, and got some confirmation that> stability went up after that change.> > -Sean> > -- > Sean Dague / Neas Bade> sdague at gmail.com> http://dague.net> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081201/04dc66a3/attachment-0001.html>