Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'd be interested to hear other answers to this, but I don't see a problem with it. The duplicate copy will be abandoned and gets GCed.</p> <p>You need to make the field <code>volatile</code> though.</p> <p>Regarding this:</p> <blockquote> <p>However, I'm surprised nobody brought up the possibility of the compiler realizing that the temp variable is unnecessary, and just assigning straight to m_PropName. If that were the case, then a reading thread could possibly read an object that hasn't finished being constructed. Does the compiler prevent such a situation?</p> </blockquote> <p>I considered mentioning it but it makes no difference. The new operator doesn't return a reference (and so the assignment to the field doesn't happen) until the constructor completes - this is guaranteed by the runtime, not the compiler.</p> <p>However, the language/runtime does NOT really guarantee that other threads cannot see a partially constructed object - <a href="http://incrediblejourneysintotheknown.blogspot.com/2009/03/readonly-fields-and-thread-safety.html" rel="nofollow noreferrer">it depends what the constructor does</a>.</p> <p><strong>Update:</strong></p> <p>The OP also wonders whether <a href="http://blog.markrendle.net/post/Lazy-initialization-thread-safety-and-my-favourite-operator.aspx" rel="nofollow noreferrer">this page has a helpful idea</a>. Their final code snippet is an instance of <a href="http://en.wikipedia.org/wiki/Double_checked_locking_pattern" rel="nofollow noreferrer">Double checked locking</a> which is the classic example of an idea that thousands of people recommmend to each other without any idea of how to do it right. The problem is that SMP machines consist of several CPUs with their own memory caches. If they had to synchronise their caches every time there was a memory update, this would undo the benefits of having several CPUs. So they only synchronize at a "memory barrier", which occurs when a lock is taken out, or an interlocked operation occurs, or a <code>volatile</code> variable is accessed.</p> <p>The usual order of events is:</p> <ul> <li>Coder discovers double-checked locking</li> <li>Coder discovers memory barriers</li> </ul> <p>Between these two events, they release a lot of broken software.</p> <p>Also, many people believe (as that guy does) that you can "eliminate locking" by using interlocked operations. But at runtime they are a memory barrier and so they cause all CPUs to stop and synchronize their caches. They have an advantage over locks in that they don't need to make a call into the OS kernel (they are "user code" only), but <a href="http://www.bluebytesoftware.com/blog/2009/01/09/SomePerformanceImplicationsOfCASOperations.aspx" rel="nofollow noreferrer">they can kill performance just as much as any synchronization technique</a>.</p> <p>Summary: threading code looks approximately 1000 x easier to write than it is.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload