Share via

Synchronization Complexity in the .NET Framework

  • Article

Several people here (you know who you are) have been nagging me to do an analysis similar to the one I did for allocations but to get an idea of which methods might do locking and how much.  So I repeated my experiment, this time counting any calls to Monitor.Enter in the subtree of any given method.

The results were very surprising, you can see that the bulk of the methods (78%) do no synchronization at all.  However, once you go down the dark path, it gets bad fast.  The synchronization complexity of the biggest is over 10^19.  Remember as with the allocation metric the number is offset by 1 so that 0 -> 0,  1 -> 1,  10->2,  100->3, etc.

Anyone care to guess what class has the methods with the greatest synchronization complexity?

In a coming article I will write a few words about how to interpret these numbers.  Clearly a complexity of 10^19 does not mean that 10^19 synchronizations actually happen when you call the method.

 

 

Comments

  • Anonymous
    February 16, 2007
    Can you explain what the axes of the graph represent? I assume the Y-axis is number of calls to Monitor.Enter, but what are the fractional values on the X-axis?

  • Anonymous
    February 17, 2007
    X axis = log10(complexity) Y axis = number of methods with that complexity

  • Anonymous
    February 17, 2007
    My guess would have to be System.Threading.Thread. It's probably not something that obvious though.

  • Anonymous
    February 18, 2007
    Maybe one of the lock classes, like ReaderWriterLock? Dunno, but this sure is interesting stuff, Rico - thanks.

  • Anonymous
    February 18, 2007
    > Anyone care to guess what class has the > methods with the greatest allocation > complexity? s/allocation/synchronization/? If the numbers mean something other than the quantity of synchronizations, I guess they relate to an average length of time that methods are expected to wait while synchronizing.  Maybe that would be clients of networking stuff.

  • Anonymous
    February 18, 2007
    >> s/allocation/synchronization/? Yes, sorry, I fixed that.

  • Anonymous
    February 18, 2007
    I'm retracting my guess because I think RWLocks would implement their own locking mechanism rather than relying on Monitor. I'll offer another vague cop-out of a guess: something in ASP.NET's caching infrastructure somewhere. Surely there'd have to be some pretty heavy locking there somewhere . . . ?

  • Anonymous
    February 21, 2007
    The comment has been removed

  • Anonymous
    February 23, 2007
    Since it's just guessing, and I don't have to browse through any classes, I'll throw out ThreadPool or WebRequest for most synch complexity, being that a thread or IO management would require a great deal of locking, and the file-based IO stuff can depend a lot on the FS to ensure locks

  • Anonymous
    March 07, 2007
    I second Norman Diamond's choice of Thread.

  • Anonymous
    March 22, 2007
    Well it seems like an eternity ago but at last I'm writing the followup to my initial question about