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

Yuval Shavit yshavit at akiban.com
Wed Oct 3 13:48:14 EDT 2012


Is that true? I was under the impression that final only has memory
visibility implications for the final field itself, and anything gotten
from it. So for instance:

class Foo {
    int a;
    final boolean ctorDone;

    Foo() {
        a = 1;
        ctorDone = true;
    }

    void verify() {
        while (!ctorDone) { /* spin */ }
        assert a == 1 : a;
    }
}

My understanding is that (assuming unsafe publication and all that) the JMM
is allowed to have a == 0 in Foo.verify, because the memory visibility only
applies to ctorDone. If ctorDone were a volatile, then reading it would
ensure a full HB edge, and you'd be guaranteed to see a == 1.

On Wed, Oct 3, 2012 at 1:32 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> We may say `final` is stronger than `volatile`, it has all the
> semantics of `volatile', and more.
>
> `volatile` is not strong enough to build thread-safe immutable
> objects, `final` is.
>
> On Wed, Oct 3, 2012 at 8:24 AM, Andy Nuss <andrew_nuss at yahoo.com> wrote:
> > Hi,
> >
> > I have a class with a single member, a reference to a new MessageDigest
> > obtained in the constructor based on the algorithm name passed to the
> > constructor.  The constructor also has a Reader argument and reads all
> the
> > data from the Reader thru an OutputStreamWriter("UTF-8) and passes thru
> to
> > the digest with my own OutputStream filter.  The call to the constructor
> > then accesses the MessageDigest member and calls digest() to get the
> > resulting byte[].  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.
> >
> > 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.
> >
> > Andy
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> _______________________________________________
> 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/018e4167/attachment.html>


More information about the Concurrency-interest mailing list