[concurrency-interest] Joda-Time immutability

Shay Banon kimchy at gmail.com
Mon Aug 1 18:31:04 EDT 2011


Risky and Correct are on two different spectrums, so thats just feels
like propaganda. I'll give my line of reasoning another shot, but as I said
before, its really up to you, I am a happy user of Joda time and thank you
for the effort of building it (and from 2.0 onwards, will have my custom
build without the volatile because I both understand the implications of it
not being volatile/final, and have problems with the performance that comes
with it).

In practice, when constructing an object on one thread and passing it to
another thread, you already go through a memory barrier (for example, some
sort of a concurrent queue), so, I think the visibility concerns, compared
to the implications of changing the variables to volatile are misplaced.
Especially since this can potentially be solved in different manners. Heck,
even introducing a new ReallyHonestToGodImmutableDateTime class :)

On Tue, Aug 2, 2011 at 12:35 AM, Stephen Colebourne <scolebourne at joda.org>wrote:

> If the choice is Correct and slower or Risky and faster, I choose correct.
>
> Stephen
>
>
> On 1 August 2011 22:15, Shay Banon <kimchy at gmail.com> wrote:
> > I just did a quick test by changing to volatile field the 1.6 release,
> and
> > on my machine I see 6x worse perf on 10 million data points (on a "real
> > world" use case in my system, end to end). Naturally, this will vary
> > depending on many aspects (number of cores, os) in terms of how volatile
> > write and read are handled. I really think that this is the wrong
> solution
> > to the "problem", but up to you...
> >
> > On Mon, Aug 1, 2011 at 11:29 PM, Stephen Colebourne <
> scolebourne at joda.org>
> > wrote:
> >>
> >> I'd be interested in any real world benchmark that indicates a
> >> significant slow down at the application level (not a micro
> >> benchmark).
> >>
> >> However, this thread didn't exactly give me any better options in line
> >> with compatibility (esp. now 2.0 is released)
> >>
> >> Stephen
> >>
> >>
> >> On 1 August 2011 19:54, Shay Banon <kimchy at gmail.com> wrote:
> >> > Hi,
> >> >   I find the solution to change to volatile fields problematic. In my
> >> > case,
> >> > I use the mutable version of the DateTime to have UTC based timestamps
> >> > converted automatically to relevant timezone and rounding, over a very
> >> > large
> >> > collection. Having volatile field means heavy writing and then reading
> >> > of
> >> > those values, which will really hurt perf. Here is an example of what
> I
> >> > do:
> >> > long[] timestamps = ... //very large dataset of timestamps
> >> > MutableDateTime time = ..
> >> > for (int i = 0; i < timestamps.length; i++) {
> >> >      time.setMillis(timestamp[i]);
> >> >      ....
> >> >      time.getMillis();
> >> > }
> >> > I think changing to volatile will hurt many more programs out there
> than
> >> > one
> >> > might think...
> >> > I would even say that the immutable values will almost always have to
> go
> >> > through a memory barrier of some sort when "transfered" to another
> >> > thread,
> >> > so in practice the volatile solution will break more code out there
> (by
> >> > it
> >> > performing badly). I think if this can't be solved in the proper way
> >> > (finals
> >> > on immutable, non volatile on mutable, and hack serialization), then
> my
> >> > vote
> >> > is to break serialization, and if not, then do nothing and make a note
> >> > in
> >> > the docs regarding the immutable values.
> >> > -shay.banon
> >> > p.s. Sorry if this discussion has diverged to pure Joda, will be happy
> >> > to
> >> > continue it on the Joda mailing list if it makes sense
> >> > On Tue, Jun 21, 2011 at 2:49 PM, Stephen Colebourne
> >> > <scolebourne at joda.org>
> >> > wrote:
> >> >>
> >> >> On 21 June 2011 09:11, Mark Thornton <mthornton at optrak.com> wrote:
> >> >> > This should be backward compatible with existing serialized
> instances
> >> >> > while
> >> >> > allowing the fields in BaseDateTime to be final. It comes at the
> >> >> > expense
> >> >> > of
> >> >> > a slightly larger MutableDateTime object, and slightly slower
> >> >> > deserialization.
> >> >>
> >> >> In the end, I think Doug's advice is probably right. Just use
> >> >> volatile. I don't think its ideal, but it "Just Works", which is a
> >> >> good thing in this codebase.
> >> >>
> >> >> Mark, I think your change would work (and I like the neat set before
> >> >> defaultReadFields). However it would have required any mutable
> >> >> application subclass to be changed, which I was hoping to avoid.
> >> >> Compared to the volatile approach I decided simple is best.
> >> >>
> >> >>
> >> >>
> >> >>
> https://github.com/JodaOrg/joda-time/commit/67f1a30fc0fceda751b6347b2b16a5081878ac1e
> >> >>
> >> >> Another variation which would also appear to work would be to change
> >> >> the data storage in BaseDateTime to a transient final two element
> >> >> array and use ObjectStreamField to read and write the existing
> >> >> serialized format. (The final array would presumably keep
> immutability
> >> >> happy, while the array settability even when final would keep the
> >> >> mutable classes happy). But the complexity was considerably greater,
> >> >> so volatile won (unless someone screams that it kills their
> >> >> performance).
> >> >>
> >> >> Thanks everyone for your thoughts.
> >> >>
> >> >> Stephen
> >> >> _______________________________________________
> >> >> 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
> >> >
> >> >
> >>
> >> _______________________________________________
> >> 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
> >
> >
>
> _______________________________________________
> 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/20110802/f8aa90d3/attachment.html>


More information about the Concurrency-interest mailing list