<p dir="ltr">Your last statement is untrue in the general case - it depends on how you publish the newly constructed instance and/or whether the fields of the class are final.</p>
<p dir="ltr">The constructor for a *given instance* is on a single thread, that part is true.  If your constructor modifies static shared state, then it's racy.  Basically, a constructor should be thought of just like a normal method in this regard.</p>

<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Oct 3, 2012 10:07 AM, "Andy Nuss" <<a href="mailto:andrew_nuss@yahoo.com">andrew_nuss@yahoo.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><span>I call close on the outputstreamwriter in the finally of the constructor, flush implied by close.   In the debugger, I see that at that point the write method in MyOutputStream is called, which calls digest.update().  The digest is SHA256.  I've walked thru my code over and over and over.  The bug only happens on one particular dual core machine, a Mac running Centos under vmware.</span><div style="font-family:times new roman,new york,times,serif;font-size:12pt">
<div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:times new roman,new york,times,serif">
<br><span></span></div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:times new roman,new york,times,serif"><span>The reason I ask about the constructor is this: java memory model provides
 a guarantee that all memory set/changed in the constructor is immediately visible to any other thread (that receives a reference to new object) after the constructor returns.  Is this true?  Is the contructor always executed in the same thread as its caller?<br>
</span></div><div><br></div>  <div style="font-family:times new roman,new york,times,serif;font-size:12pt"> <div style="font-family:times new roman,new york,times,serif;font-size:12pt"> <div dir="ltr"> <font face="Arial"> <hr size="1">
  <b><span style="font-weight:bold">From:</span></b> Aleksey Shipilev <<a href="mailto:aleksey.shipilev@oracle.com" target="_blank">aleksey.shipilev@oracle.com</a>><br> <b><span style="font-weight:bold">To:</span></b> Andy Nuss <<a href="mailto:andrew_nuss@yahoo.com" target="_blank">andrew_nuss@yahoo.com</a>> <br>
<b><span style="font-weight:bold">Cc:</span></b> "<a href="mailto:concurrency-interest@cs.oswego.edu" target="_blank">concurrency-interest@cs.oswego.edu</a>" <<a href="mailto:concurrency-interest@cs.oswego.edu" target="_blank">concurrency-interest@cs.oswego.edu</a>> <br>
 <b><span style="font-weight:bold">Sent:</span></b> Wednesday, October 3, 2012 6:47 AM<br>
 <b><span style="font-weight:bold">Subject:</span></b> Re: [concurrency-interest] do constructors ever involve threading under the covers?<br> </font> </div> <br>
Hi Andy,<br><br>On 10/03/2012 05:24 PM, Andy Nuss wrote:<br>> My code by all appearances is single<br>> threaded, but I am having strange bugs that on one particular machine<br>> running vmware, the digest result I am getting (for password hashing)<br>
> appears not to be repeatable.<br><br>I don't think this has something to do with concurrency at all. Are you<br>sure you are reading up all the buffers, flushing and closing the<br>streams appropriately, etc? What if you have your own dummy<br>
implementation of MessageDigest which only counts the consumed data<br>size? A test case would be helpful.<br><br>> Basically, I am wondering if another thread can execute the body of the<br>> constructor (or in the construction and use of the OutputStreamWriter,<br>
> within my constructor) that could be causing a bug where memory written<br>> by the MessageDigest.update() function (triggered within the constructor<br>> by writing thru
 OutputStreamWriter) is not seen in the call to digest()<br>> on the newly created MessageDigest member after the constructor returns.<br><br>While the construction you describe here is possible, most MessageDigest<br>
implementations are not threaded, and so both update() and digest() are<br>getting executed in the single callee context, which means there is no<br>races. Even if there are digest providers which execute update() and/or<br>
digest() in separate threads, I would be surprised if they are not<br>enforcing any particular ordering (given concurrent update()-s make<br>sense for hashing at all).<br><br>-Aleksey.<br><br><br><br> </div> </div>  </div>
</div></div><br><br> </div> </div>  </div></div><br>_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br></blockquote></div>