[concurrency-interest] Visibility of lazy intialisation

Jan Nielsen Jan.Nielsen at sungardhe.com
Tue Jul 18 11:58:23 EDT 2006


For lazy initialization of singletons, consider using the Initialization 
on Demand Holder Idiom:



Jan Nielsen * System Architect * SunGard Higher Education * Tel +1 801 257 
4155 * Fax +1 801 485 6606 * jan.nielsen at sungardhe.com * www.sungardhe.com 
* 90 South 400 West, Suite 500, Salt Lake City, UT USA

CONFIDENTIALITY: This email (including any attachments) may contain 
confidential, proprietary and privileged information, and unauthorized 
disclosure or use is prohibited.  If you received this email in error, 
please notify the sender and delete this email from your system. Thank 

"Mike Quilleash " <mike.quilleash at subexazure.com> 
Sent by: concurrency-interest-bounces at cs.oswego.edu
07/18/2006 07:05 AM

concurrency-interest at cs.oswego.edu

[concurrency-interest] Visibility of lazy intialisation

I have a static singleton that I want to lazy initialise.
Currently the code I have looks like this
private static Helper helper = null;
public synchronized static Helper getHelper() throws HelperException
  if ( helper == null )
    Helper localHelper = new Helper();
    helper = locaHelper;
  return helper;
The initialise() function may throw an exception which I want to propogate 
up and catch somewhere higher.  I'm wondering if it definately the case 
that the helper variable will NOT be null if an exception is thrown in the 
Helper constructor or initialise().  Can the JVM/OS/CPU reorder the 
instructions so that helper is set before initialise is executed?
Should I instead be using one of the static initialise idions, like a 
static class?  My problem would then become how to catch the initialise 
when it is in a static code block.
Cheers for any help/advice.
This e-mail is bound by the terms and conditions described at 
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu

More information about the Concurrency-interest mailing list