On Tue, 11 Apr 2006 00:16:42 +0300, Kamen Lilov <[EMAIL PROTECTED]> wrote:
>If you're asking about the point of using the pattern below (locking only on >writes, not on reads)... well... It can only work with atomic types, and >when reader threads can afford to get stale data. In other words, it won't >work in 99% of the real-world cases, and just shows the developer did not >understand the subject matter. Precisely what you saw yourself :) Correct, and my example is only atomic on 64-bit systems. If the programmer cares that myValue could change between when the value is retrieved and when amount is added to it--in the Add method--they should also care that myValue could change in the middle of the retrieval in the property get. After seeing this so many times, what has me curious (apart from whether or not correct Interlocked usage is widely known) is why the programmer added the Interlocked on the write, but not the read. > >If you're asking whether, e.g., InterlockedIncrement has better performance >than a higher-level primitive (e.g. a Windows CRITICAL_SECTION) -- well... >my observations (and I've done some serious work in the area) would be -- >doesn't matter too much. I think it's pretty clear that Interlocked generally has better performance than other primitives. But, I have to agree, it shouldn't matter too much. If you've got that many race conditions, that switching from lock to Interlocked.*rement is going to increase performance dramatically, there's bigger issues. My tests have shown that Interlocked.Increment (in a non-contentious scenarios, the best case) is about half as slow as lock/Monitor.Enter-Exitt--in my tests, the differences between ~89 microseconds and ~34 microseconds. But, Interlocked.Increment is still over 10 times slower than not using Interlocked.Increment at all. Designing for low-locking is obviously the way to go. >In other words, the real performance killer is the things the CPU needs to >do to the cache and the system bus whenever sync primitives are involved; >you're not likely to see CRITICAL_SECTION working much slower than your >average assembly-language coded LOCK:-prefixed increment and exchange >instruction (that's what InterlockedIncrement really is) > >Kamen Lilov >http://www.delera.com > > >-----Original Message----- >From: Discussion of advanced .NET topics. >[mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie >Sent: Saturday, April 08, 2006 5:13 PM >To: [email protected] >Subject: Re: [ADVANCED-DOTNET] Interlocked.Increment/Decrement/Add > >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); >} >// ... > >[snip deleted] > >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. > >[snip deleted] =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
