[concurrency-interest] do constructors ever involve threading under the covers?
vitalyd at gmail.com
Wed Oct 3 10:20:22 EDT 2012
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.
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
Sent from my phone
On Oct 3, 2012 10:07 AM, "Andy Nuss" <andrew_nuss at yahoo.com> wrote:
> 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).
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest