Well I interpret your original question in 2 different ways, so here's two answers:
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 :) 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. 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
