[concurrency-interest] BigDecimal Safe Publication

Vitaly Davidovich vitalyd at gmail.com
Mon Aug 20 15:35:35 EDT 2012


Publishing through volatile reference is not a data race - a lot of jdk
classes publish safely via a write/read through volatile, it's a valid
hand-off technique.  Can you explain why you think it's a data race?

Sent from my phone
On Aug 20, 2012 2:01 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:

> The advice is a little hard to follow, since both tricks, publish
> through volatile reference, and publish immutable objects, contain
> data race by JMM's definition.
>
> On Mon, Aug 20, 2012 at 7:14 AM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> > Indeed, that seems to be the advice of this month on this list. :)
> >
> > Sent from my phone
> >
> > On Aug 20, 2012 8:05 AM, "Sergey Kuksenko" <skuksenko at gmail.com> wrote:
> >>
> >> Publishing via data race would be a problem with a lot classes. Just
> Don't
> >> do it. :)
> >>
> >> On Mon, Aug 20, 2012 at 3:45 PM, Vitaly Davidovich <vitalyd at gmail.com>
> >> wrote:
> >>>
> >>> I think James was talking about publishing via data race, in which case
> >>> it would indeed be a problem with that version.
> >>>
> >>> Sent from my phone
> >>>
> >>> On Aug 20, 2012 7:41 AM, "Sergey Kuksenko" <skuksenko at gmail.com>
> wrote:
> >>>>
> >>>> Hi James,
> >>>>
> >>>> - Look into jdk8 sources. New  BigDecimal has final fields (instead of
> >>>> volatile).
> >>>> - Could you explain what is the issue for safe publication in the old
> >>>> code (look like everything is ok)?
> >>>>
> >>>> On Mon, Aug 20, 2012 at 2:58 PM, James <james at inaseq.com> wrote:
> >>>>>
> >>>>> I'm wondering whether the BigDecimal constructors that take a
> >>>>> MathContext parameter exhibit initialization safety.  As far as I
> can tell
> >>>>> (and I could be very wrong), BigDecimal is relying on the volatile
> nature of
> >>>>> the intVal reference to ensure the BigDecimal is effectively
> immutable.
> >>>>> However, the constructors that take a MathContext delegate to the
> following
> >>>>> method, which alters other members after intVal:
> >>>>>
> >>>>>     private void roundThis(MathContext mc) {
> >>>>>         BigDecimal rounded = doRound(this, mc);
> >>>>>         if (rounded == this)                 // wasn't rounded
> >>>>>             return;
> >>>>>         this.intVal     = rounded.intVal;
> >>>>>         this.intCompact = rounded.intCompact;
> >>>>>         this.scale      = rounded.scale;
> >>>>>         this.precision  = rounded.precision;
> >>>>>     }
> >>>>>
> >>>>> Is this a potential issue for safe publication or am I missing
> >>>>> something?
> >>>>> Is BigDecimal intended to exhibit initialization safety?
> >>>>> _______________________________________________
> >>>>> Concurrency-interest mailing list
> >>>>> Concurrency-interest at cs.oswego.edu
> >>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Sergey Kuksenko
> >>>>
> >>>> _______________________________________________
> >>>> Concurrency-interest mailing list
> >>>> Concurrency-interest at cs.oswego.edu
> >>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>>>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Sergey Kuksenko
> >
> >
> > _______________________________________________
> > 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/20120820/a8aece0a/attachment-0001.html>


More information about the Concurrency-interest mailing list