Prev: Design time serialization!
Next: A working custom control but why do I need to have the enum as public
From: Tony Johansson on 15 May 2010 05:45
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


From: Willem van Rumpt on 15 May 2010 07:05
On 15-5-2010 11:45, Tony Johansson wrote:
> 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.

--
Willem van Rumpt
From: Arne Vajhøj on 15 May 2010 17:34
On 15-05-2010 05:45, Tony Johansson wrote:
> 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

From: Peter Duniho on 16 May 2010 20:30
Willem van Rumpt wrote:
> On 15-5-2010 11:45, Tony Johansson wrote:
>> 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.

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
From: Peter Duniho on 16 May 2010 20:38
Arne Vajh�j wrote:
> On 15-05-2010 05:45, Tony Johansson wrote:
>> 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.

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
 | 
Pages: 1
Prev: Design time serialization!
Next: A working custom control but why do I need to have the enum as public