Locking in C#

[Akula]

Does anyone know whether or not it is faster to lock a simple object,
rather than a complex type?

For example:

Dictionary<string, SomeOtherClass> dict = new Dictionary<string,
SomeOtherClass>();
object lockObject = new object();

--- Example 1 ---

lock (dict)
{
// Do something with dict
}

--- Example 2 ---

lock (lockObject)
{
// Do something with dict
}

I have seen a improvment in performance in the simple object locking
v.s. locking the entire dictionary, but what are the side affects?
And why am I seeing that improvment in the first place?

Thanks

 

[Nicholas Paldino [.NET/C# MVP]]

Akula,

I doubt you have seen a performance improvement, as what is actually
being locked on is an internal member of the object which has nothing to do
with anything else in the object (it's type, members, etc, etc).

If you are seeing a difference, I would wager that it is in the cost of
constructing the different objects, and not actually locking on them.

 

[Jon Skeet [C# MVP]]

Does anyone know whether or not it is faster to lock a simple object,
rather than a complex type?

You don't lock an object - you lock a reference. The locking itself
doesn't really interact with the object.

I have seen a improvment in performance in the simple object locking
v.s. locking the entire dictionary, but what are the side affects?
And why am I seeing that improvment in the first place?

I suspect you're seeing the improvement due to flaws in your
benchmarking methodology, although it's hard to say without seeing the
code.

However, I personally almost always use a separate object to provide
the reference for locking, as this means I can ensure it's never made
publically available, which helps to avoid threading issues.

 

[Akula]

Interesting... but there is a definite performance increase when I
merely switch the object being locked (from a class, to a simple
object).

Is there a resource on the web that describes, in detail, the
internals of the lock statement? I have looked at my complied code
using ildasm, and like you said, there appears to be no difference in
how it locks.

 

[Jon Skeet [C# MVP]]

Interesting... but there is a definite performance increase when I
merely switch the object being locked (from a class, to a simple
object).

Could you post a short but complete program which demonstrates this?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

Is there a resource on the web that describes, in detail, the
internals of the lock statement? I have looked at my complied code
using ildasm, and like you said, there appears to be no difference in
how it locks.

Lock just compiles into pair of calls to Monitor.Enter/Exit with
try/finally.

 

[Nicholas Paldino [.NET/C# MVP]]

Akula,

You will want to take a look for anything that calls the static Enter
method on the Monitor class, as that is what the call compiles down to.

I imagine that what Jon said is correct, that you are not gathering the
metrics correctly.

This is how it should look:

// The object to lock on.
object objectToLockOn = new object();

// The stopwatch.
Stopwatch sq = new Stopwatch();

// Start the stopwatch.
sw.Start();

// Lock.
lock (objectToLockOn)
{
// Stop the stopwatch.
sw.Stop();
}

// Do something with the results here.

I imagine that you will have to collect the time over a number of calls
in order to determine how much time it takes to acquire the lock. In my own
tests, I found there was negligible difference iterating over one million
times (for a tital difference of .3 seconds).

 

[Akula]

Ok, so after some more investigation, and downloading some new
profiling tools, I have determined that it was the profiler that I was
using.

So, those of you who were suggesting that the metrics I was gathering
were wrong are correct.

Thanks for the help, all.

 

[Scott Gifford]

Interesting... but there is a definite performance increase when I
merely switch the object being locked (from a class, to a simple
object).

Is there a resource on the web that describes, in detail, the
internals of the lock statement? I have looked at my complied code
using ildasm, and like you said, there appears to be no difference in
how it locks.

I found Jon's article here very helpful in understanding how C#
locking works:

http://www.yoda.arachsys.com/csharp/threads/locking.shtml

----Scott.