about the interlocked class and the lock keyword

[Tony Johansson]

Hi!

Assume I just increment a value in a class so I can use the interlocked
class.
If I instead of using the interlocked class I use the lock which underneth
is using the monitor class
will the performance be effected in any major way.

So I just wonder about how much overhead there is if I use the lock keyword
instead of using the interlocked in those places
where I can use interlocked.

//Tony

 

[Willem van Rumpt]

Hi!

So I just wonder about how much overhead there is if I use the lock keyword
instead of using the interlocked in those places
where I can use interlocked.

//Tony

The Interlocked class has superior performance compared to a lock.
But the two are not interchangeable, i.e. you can not go around
switching to one of the Interlocked methods where you use a lock and
vice versa.

 

[Arne Vajhøj]

Assume I just increment a value in a class so I can use the interlocked
class.
If I instead of using the interlocked class I use the lock which underneth
is using the monitor class
will the performance be effected in any major way.

So I just wonder about how much overhead there is if I use the lock keyword
instead of using the interlocked in those places
where I can use interlocked.

That is implementation specific.

You can not assume that just because .NET 2.0 on a 32
bit XP behaves one way that a .NET 4.0 on 64 bit 7 will
act the same way.

Go for readable code and don't waste time micro optimizing
stuff like this.

Arne

 

[Peter Duniho]

The Interlocked class has superior performance compared to a lock.
But the two are not interchangeable, i.e. you can not go around
switching to one of the Interlocked methods where you use a lock and
vice versa.

That's only half true (i.e. the statement was fine until the words "and
vice versa" showed up ). You can replace the use of Interlocked with
a "lock" statement. If this works in one's code:

int i;

void Method()
{
Interlocked.Increment(ref i);
}

…then this will work just as well:

int i;
readonly object objLock = new object();

void Method()
{
lock (objLock)
{
i++;
}
}

You are correct that a "lock" statement may or may not be replaceable by
a use of the Interlocked class. That would depend on what the code
within the "lock" statement is actually doing.

Pete

 

[Peter Duniho]

That is implementation specific.

I assume you are speaking strictly of the _performance_ characteristics,
rather than the question of being able to use the Interlocked class in
place of the "lock" class.

You can not assume that just because .NET 2.0 on a 32
bit XP behaves one way that a .NET 4.0 on 64 bit 7 will
act the same way.

The Interlocked class in .NET has specific promises about what it does.
It's not platform-dependent. So, assuming the Interlocked class is
providing the thread-safe semantics needed by the program, it will
behave itself.

As far as the performance goes, I doubt there's a .NET implementation
where the Interlocked class is _slower_ than the "lock" statement. But
I suppose anything's possible.

Go for readable code and don't waste time micro optimizing
stuff like this.

When the semantics being implemented is _exactly_ what the Interlocked
class provides (e.g. incrementing a variable, or compare-and-swap, etc.)
then I don't see it as a micro-optimization. If anything, a single
program statement using the Interlocked class can be described as more
readable than having to add a synchronization object and a "lock"
statement around the program statement doing the actual work.

On the other hand, the Interlocked class is often used to control
variables involved in lock-free thread-safe implementations. And yes,
that would definitely be a micro-optimization where using the "lock"
statement is a more readable, more maintainable, and likely completely
sufficient way to implement the code.

Pete