Brian, Mike.
Could you explain what is the problem with the old caching?
String is immutable, BigDecimal is immutable. So we have data race at
that place, but it is safe data race. What is the problem if we create
several identical strings?
You are making stringCache volatile -> performance penalty on ARM & PPC.
Setting cache via CAS -> performance penalty everywhere.
If you insist to use AtomicFieldUpdater - the better way is to use
lazySet, not CAS.
On 03/04/2014 09:21 PM, Mike Duigou wrote:
On Mar 4 2014, at 07:13 , Peter Levart <peter.lev...@gmail.com> wrote:
On 03/04/2014 01:14 AM, Brian Burkhalter wrote:
- add AtomicReferenceFieldUpdater-type constant for stringCache initialization
Hi Brian,
By using volatile read and CAS, there's still a chance that multiple concurrent
threads will be invoking the layoutChars(true) concurrently, but you guarantee
that only a single instance of String will ever be returned as a result of the
toString() method. Is that what you were pursuing?
Yes. (I provided the AtomicReferenceFieldUpdater code). The previous
implementation had a benign data race that could result in a later layoutChars
result replacing an earlier result and multiple string instances being
returned. The new implementation, at small cost, prevents multiple different
instances from being returned.
Mike
--
Best regards,
Sergey Kuksenko
