[concurrency-interest] Joda-Time immutability

Shay Banon kimchy at gmail.com
Mon Aug 1 14:54:36 EDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110801/277b7bf8/attachment.html>


More information about the Concurrency-interest mailing list