More recently (keeping it to .NET), I've seen things like:
// ...
private Int64 myValue;
public Int64 MyValue
{
get { return myValue; }
}
public void Add(Int64 amount)
{
Interlocked.Add(myValue, amount);
}
// ...
Or:
private Int32 myValue;
//...
public void SomeFunction()
{
//...
Interlocked.Increment(myValue);
//...
}
public void SomeOtherFunction()
{
Int32 n;
// ...
myValue += n;
// ...
}
But, my favourite is when programmers use Interlocked.Increment in private
code that cannot be executed by more than one thread at a time (like
private background worker thread method) simply because it occurs in a
background thread.
Programmers seem to think ensuring atomicity of an operation is only
important on the write (the first example). Which may stem from the fact
that with Int32 this may be true; but, they telescope the pattern onto
other, not natively atomic, types. Which seems to be reinforced by the
fact that Interlocked doesn't provide a method to atomically read the
value. Ironically, this didn't even occur to the framework designers
until 2.0, when the ability to atomically read an Int64 via
Interlocked.Read() was added. This probably stems from most .NET
programmers were Win32 programmers previously and Win32's
InterlockedIncrement() is documented as "prevents more than one thread
from using the same variable simultaneously"
I categorize it as "premature optimization" [1] [2]; but, I prefer to
avoid Interlocked until I know I have a performance issue. Then, only
after thorough analysis, decide that Interlocked can be used in place of
lock, in certain places. Programmers seem to do it the other way around,
use Interlocked first, then realized they've painted themselves into a
corner.
One thing that bothers me about Interlocked is its lack of scalability--in
terms of evolution. If you go down the route of using Interlocked for
some value types; then have to include that value type in a compound
invariant, or need to write a block of code that needs to lock the value
type, you have to back-out your use of Interlocked.* and replace it with
lock/Monitor.Enter,.Exit.
Not the most amusing WTF I've come across, but certainly makes you wonder.
[1] http://en.wikipedia.org/wiki/Software_optimization
[2] http://blogs.msdn.com/LarryOsterman/archive/2004/05/03/125198.aspx
On Fri, 7 Apr 2006 22:29:34 +0200, Peter van der Weerd <[EMAIL PROTECTED]>
wrote:
>Hi Peter,
>
>Can you give us some samples of that strange usage? I'm curious.
>
>P
>
>
>----- Original Message -----
>From: "Peter Ritchie" <[EMAIL PROTECTED]>
>To: <[email protected]>
>Sent: Friday, April 07, 2006 8:46 PM
>Subject: Re: [ADVANCED-DOTNET] Interlocked.Increment/Decrement/Add
>
>
>| Don't get me wrong; I'm not asking how to use the Interlocked class.
I'm
>| looking more for the decisions leading up other people's use of
>| Interlocked.
>|
>| Scott has a correct answer with the C# increment operator is not atomic
>| and if called from multiple threads will result in random data. Same
>| holds true for +=, -=, --, /=, *=, etc. But, he qualifies it with
>| multiple threads.
>|
>| I've seen some pretty strange uses of
>| Interlocked.Increment/InterlockedIncrement over the years and was
curious
>| of people's concept of the methods and the semantics.
>|
>| On Fri, 7 Apr 2006 14:06:31 -0400, Shawn Wildermuth
>| <[EMAIL PROTECTED]> wrote:
>|
>| >Performance....they are a lot faster than a lock and much lighter
weight.
>| >THere is a great discussion of them in Jeffrey Richter's new book "CLR
>via
>| >C#". I'd suggest picking that up.
>| >
>| >
>| >
>| >
>| >Thanks,
>| >
>| >Shawn Wildermuth
>| >http://adoguy.com
>| >C# MVP, MCSD.NET, Author and Speaker
>| >
>| >
>| >-----Original Message-----
>| >From: Discussion of advanced .NET topics.
>| >[mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie
>| >Sent: Friday, April 07, 2006 1:41 PM
>| >To: [email protected]
>| >Subject: [ADVANCED-DOTNET] Interlocked.Increment/Decrement/Add
>| >
>| >The topic of using Interlocked.Increment(Int32) came up elsewhere, and
I
>| was
>| >wondering what other's in the community were doing with Interlocked in
>| their
>| >code and their coding guidelines.
>| >
>| >If you're using Interlocked.Increment(Int32), .Decrement(Int32),
or .Add
>| >(Int32, Int32), in particular, what are you expectations of these
>methods?
>| >Why have you chosen them over equivalent language syntax?
>| >
>| >I'd also be interested on your thoughts on
>| >Interlocked.Increment/Decrement/Add(Int64). Do you use the
corresponding
>| >Interlocked.Read(Int64) as well?
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
