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

Vitaly Davidovich 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
this regard.

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).
>
> -Aleksey.
>
>
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121003/7cf1c25a/attachment-0001.html>


More information about the Concurrency-interest mailing list