As per Fortyfy analysis report - Double-checked locking is an incorrect idiom
that does not achieve the intended effect
F ollowing code is written to guarantee that only one Fitzer() object is ever
allocated, but does not want to pay the cost of synchronization every time this
code is called
locking is an incorrect idiom that
does not achieve the intended effect
F ollowing code is written to guarantee that only one Fitzer() object is ever
allocated, but does not want to pay the cost of synchronization every time this
code is called. This idiom is known as double-checked locking
locking is an incorrect
idiom that does not achieve the intended effect
F ollowing code is written to guarantee that only one Fitzer() object is
ever allocated, but does not want to pay the cost of synchronization every
time this code is called. This idiom is known as double-checked locking
and the community is in agreement
that it is a pattern to avoid.
If you see DCL code in OFBiz, it is because no one has taken the time to fix it.
-Adrian
On 1/9/2013 1:04 PM, Sumit Pandit wrote:
As per Fortyfy analysis report - Double-checked locking is an incorrect idiom that
does not achieve
As the article and the book (Java Concurrency In Practice) both point out - the
motivation for using DCL (to overcome slow speed) is less of an issue (or a
non-issue) with newer JVMs.
I am not a Java expert. But enough Java experts have stressed the need to
eliminate this anti-pattern that I
Thanks Adrian,
Are they examples from the books or your own?
Jacques
From: Adrian Crum adrian.c...@yahoo.com
As the article and the book (Java Concurrency In Practice) both point out - the motivation for using DCL (to overcome slow speed)
is less of an issue (or a non-issue) with newer JVMs.
The static field example is from the book.
-Adrian
--- On Sat, 7/3/10, Jacques Le Roux jacques.le.r...@les7arts.com wrote:
Thanks Adrian,
Are they examples from the books or your own?
Jacques
From: Adrian Crum adrian.c...@yahoo.com
As the article and the book (Java Concurrency In
Adrian Crum wrote:
As the article and the book (Java Concurrency In Practice) both point out -
the motivation for using DCL (to overcome slow speed) is less of an issue (or
a non-issue) with newer JVMs.
I am not a Java expert. But enough Java experts have stressed the need to
eliminate
--- On Sat, 7/3/10, Adam Heath doo...@brainfood.com wrote:
Adrian Crum wrote:
As the article and the book (Java Concurrency In
Practice) both point out - the motivation for using DCL (to
overcome slow speed) is less of an issue (or a non-issue)
with newer JVMs.
I am not a Java expert.
I've been working in the conversion system lately, and discovered a
problem with it's DCL anti-pattern usage. This is not meant to single
out the conversion framework, it's just a convient example.
In Converters.getConverter(Class, Class), there is this pattern:
===
Converter result =
Adam Heath wrote:
I've been working in the conversion system lately, and discovered a
problem with it's DCL anti-pattern usage. This is not meant to single
out the conversion framework, it's just a convient example.
In Converters.getConverter(Class, Class), there is this pattern:
===
Adrian Crum wrote:
I agree that DCL is a bad pattern to use, and coincidentally, I was
researching the subject last weekend - hoping to find a good alternative
to propose to the community.
Ofbiz has generally been very luck with it's use of DCL. Most cases
are hit at startup, and from then
12 matches
Mail list logo
