Hello Keith and Andrew, The docs are right.
Multiple threads could have past the first if statement and wait for the lock to become free. However most of the time, you want exactly one thread to do the operation.(whatever that is...) After doing the operation, the lock is free for another thread to enter. Without the second if, the operation will execute again. And after the operation has execute, the first if will block future threads from acquiring a lock, which is a performance gain. (though a little) Regards, Ryan -----Original Message----- From: Keith Hill [mailto:[EMAIL PROTECTED]] Sent: woensdag 1 mei 2002 07:13 To: [EMAIL PROTECTED] Subject: [DOTNET] Threading Design Guidellines docs I have been reading the docs on Threading Design Guidelines for Class Library Developers and I ran across the following section I just don't follow. Here is the first part of it: Be aware of issues with the lock statement (SyncLock in Visual Basic). It is tempting to use the lock statement to solve all threading problems. However, the System.Threading.Interlocked Class is superior for updates that must be made automatically. It executes a single lock prefix if there is no contention. In a code review, you should watch out for instances like the one shown in the following example. lock(this) { myField++; } So I was expecting the docs to recommend doing something like this instead: Interlocked.Increment(myField); Instead, it goes on to say this (the second part): Alternatively, it might be better to use more elaborate code to create rhs outside of the lock, as in the following example. Then, you can use an interlocked compare exchange to update x only if it is still null. This assumes that creation of duplicate rhs values does not cause negative side effects. if (x == null) { lock (this) { if (x == null) { // Perform some elaborate code to create rhs. x = rhs; } } } I don't follow the code above. Can anybody shed some light on this guideline. -- Keith You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. ------------------------------------- The information included in this message is personal and/or confidential and intended exclusively for the addressees as stated. This message and/or the accompanying documents may contain confidential information and should be handled accordingly. If you are not the intended reader of this message, we urgently request that you notify Centric immediately and that you delete this e-mail and any copies of it from your system and destroy any printouts immediately. It is forbidden to distribute, reproduce, use or disclose the information in this e-mail to third parties without obtaining prior permission from Centric. We expressly point out that there are risks associated with the use of e-mail. Centric and the companies within the group shall not accept any liability whatsoever for damage resulting from the use of e-mail. Legally binding obligations can only arise for Centric by means of a written instrument, signed by an authorized representative of Centric. ------------------------------------- You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
