Is using ReaderWriterLockSlim a bad idea for long lived objects?
Posted
by uriDium
on Stack Overflow
See other posts from Stack Overflow
or by uriDium
Published on 2010-06-14T09:57:30Z
Indexed on
2010/06/14
10:02 UTC
Read the original article
Hit count: 451
I am trying to track down the reason that an application has periods of bad performance. I think that I have linked the bad performance to the points where Garbage Collection is run for Gen 2. I get a profiling tool (CLR Profiler) and was quite surprised by the results. In my test I was spawning and processing millions of objects. However the biggest hog of the Gen 2 space comes from something Called Threading.ReaderWriterCount which comes from System.Threading.ReaderWriterLockSlim::InitializeThreadCounts. I know nothing about the inner workings of ReaderWriterLockSlim but from what I am getting from the reports it is okay to have 1 or 2 Locks for longer lived objects but try and use other locks if you are going to have many smaller objects.
Does anyone have any comments or experience with ReaderWriterLockSlim and/or what to look for if it seems that GC is killing application performance?
© Stack Overflow or respective owner