[concurrency-interest] do constructors ever involve threading under the covers?

Andy Nuss andrew_nuss at yahoo.com
Wed Oct 3 10:04:48 EDT 2012


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.


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?



________________________________
 From: Aleksey Shipilev <aleksey.shipilev at oracle.com>
To: Andy Nuss <andrew_nuss at yahoo.com> 
Cc: "concurrency-interest at cs.oswego.edu" <concurrency-interest at cs.oswego.edu> 
Sent: Wednesday, October 3, 2012 6:47 AM
Subject: Re: [concurrency-interest] do constructors ever involve threading under the covers?
 
Hi Andy,

On 10/03/2012 05:24 PM, Andy Nuss wrote:
> My code by all appearances is single
> threaded, but I am having strange bugs that on one particular machine
> running vmware, the digest result I am getting (for password hashing)
> appears not to be repeatable.

I don't think this has something to do with concurrency at all. Are you
sure you are reading up all the buffers, flushing and closing the
streams appropriately, etc? What if you have your own dummy
implementation of MessageDigest which only counts the consumed data
size? A test case would be helpful.

> Basically, I am wondering if another thread can execute the body of the
> constructor (or in the construction and use of the OutputStreamWriter,
> within my constructor) that could be causing a bug where memory written
> by the MessageDigest.update() function (triggered within the constructor
> by writing thru
 OutputStreamWriter) is not seen in the call to digest()
> on the newly created MessageDigest member after the constructor returns.

While the construction you describe here is possible, most MessageDigest
implementations are not threaded, and so both update() and digest() are
getting executed in the single callee context, which means there is no
races. Even if there are digest providers which execute update() and/or
digest() in separate threads, I would be surprised if they are not
enforcing any particular ordering (given concurrent update()-s make
sense for hashing at all).

-Aleksey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121003/112a8aed/attachment.html>


More information about the Concurrency-interest mailing list