I came to the conclusion that it wouldn't fix it. You can review the
java memory model mailing list for today to find out why. Look for the
"solution to double-check locking" thread.
James Stauffer wrote:
I have thought that pattern would fix the problem also but I have
never seen anyone mention it before.
On 12/2/05, Trenton D. Adams <[EMAIL PROTECTED]> wrote:
Actually, a co-worker and I just came up with a possible solution.
public static Object getInstance()
{
if (instance == null)
createInstance();
return instance;
}
private static synchronized void createInstance()
{
if (instance == null)
instance = new Object();
}
So, we end up having the required synchronized method, but without the
normal performance hit.
Ok, I'm done now. :)
Curt Arnold wrote:
On Dec 1, 2005, at 8:39 PM, Trenton D. Adams wrote:
As a general rule, singleton methods should not be synchronized for
performance reasons. If this method is only called once in awhile,
no big deal. But, if it's called regularly, then it can be a really
big performance problem. Does the log4j project have coding
standards for such things?
This particular singleton method should check the
"_defaultLogMonitor" for null first. If it is not null, it should
return it. If it is null, it should synchronize on some object,
perhaps LF5Appender.class. Then it should check it for null again.
If it is not null, it should return it. If it is null, it should
construct it.
That idiom is not thread-safe but the explanation is too complicated to
go into here. See "The Double-Checked Locking is Broken" Declaration
(http://www.cs.umd.edu/~pugh/java/memoryModel/
DoubleCheckedLocking.html). Also covered on pg 193 of "Effective Java"
which I highly recommend.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Trenton D. Adams
Systems Analyst/Web Software Engineer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
James Stauffer
Are you good? Take the test at http://www.livingwaters.com/good/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Trenton D. Adams
Systems Analyst/Web Software Engineer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
