[jira] Issue Comment Edited: (LANG-609) Support lazy initialization using atomic variables

["Alexander Apanasovich (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LANG-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915328#action_12915328 ] 

Alexander Apanasovich edited comment on LANG-609 at 9/28/10 12:28 AM:
----------------------------------------------------------------------

There is one more variant of the implementation, which should not have that drawback described in class javadocs:

??The drawback is that the {@link #initialize()} method can be called multiple times which may be problematic if the creation of the managed object is expensive. As a rule of thumb this initializer implementation is preferable if there are not too many threads involved and the probability that multiple threads access an uninitialized object is small. If there is high parallelism, {@link LazyInitializer} is more appropriate.??

{code}
/**
 * Concurrent lazy initializer which guarantees concurrent access and initialization during the first access.
 * This implementation also guarantees that the factory method (initialize) will be only invoked once.
 */
public abstract class AtomicInitializer<T> {
    private final AtomicReference<AtomicInitializer<T>> factory = new AtomicReference<AtomicInitializer<T>>();
    private final AtomicReference<T> instance = new AtomicReference<T>();

    /**
     * Get (and initialize, if not initialized yet) the required object
     *
     * @return lazily initialized object
     */
    public final T get() throws ConcurrentException {
        T result;

        while ((result = instance.get()) == null) {
            if (factory.compareAndSet(null, this)) {
                instance.compareAndSet(null, initialize());
            }
        }

        return result;
    }

    /**
     * Factory method, which is invoked once during first call to {@link #get()}
     *
     * @return new object
     */
    protected abstract T initialize() throws ConcurrentException;
}
{code}

Sometimes the initialize method is expensive or dangerous to be called more than once, so this implementation will guarantee single initialization and concurrent access while having possibly a bit higher speed than LazyInitializer, because there is no synchronization. 

(changed private fields to final)

      was (Author: apanasovich):
    There is one more variant of the implementation, which should not have that drawback described in class javadocs:

??The drawback is that the {@link #initialize()} method can be called multiple times which may be problematic if the creation of the managed object is expensive. As a rule of thumb this initializer implementation is preferable if there are not too many threads involved and the probability that multiple threads access an uninitialized object is small. If there is high parallelism, {@link LazyInitializer} is more appropriate.??

{code}
/**
 * Concurrent lazy initializer which guarantees concurrent access and initialization during the first access.
 * This implementation also guarantees that the factory method (initialize) will be only invoked once.
 */
public abstract class AtomicInitializer<T> {
    private AtomicReference<AtomicInitializer<T>> factory = new AtomicReference<AtomicInitializer<T>>();
    private AtomicReference<T> instance = new AtomicReference<T>();

    /**
     * Get (and initialize, if not initialized yet) the required object
     *
     * @return lazily initialized object
     */
    public final T get() throws ConcurrentException {
        T result;

        while ((result = instance.get()) == null) {
            if (factory.compareAndSet(null, this)) {
                instance.compareAndSet(null, initialize());
            }
        }

        return result;
    }

    /**
     * Factory method, which is invoked once during first call to {@link #get()}
     *
     * @return new object
     */
    protected abstract T initialize() throws ConcurrentException;
}
{code}

Sometimes the initialize method is expensive or dangerous to be called more than once, so this implementation will guarantee single initialization and concurrent access while having possibly a bit higher speed than LazyInitializer, because there is no synchronization. 

  
> Support lazy initialization using atomic variables
> --------------------------------------------------
>
>                 Key: LANG-609
>                 URL: https://issues.apache.org/jira/browse/LANG-609
>             Project: Commons Lang
>          Issue Type: New Feature
>          Components: lang.concurrent.*
>            Reporter: Oliver Heger
>            Priority: Minor
>             Fix For: 3.0
>
>         Attachments: AtomicInitializer.patch
>
>
> In the new concurrent package there is already the {{LazyInitializer}} class implementing the double-check idiom for lazy initialization of instance fields. Another way to perform initialization lazily would be the usage of atomic variables. This solution would not need synchronization at all. If there is low contention (not many threads in parallel), it is more efficient than synchronized access. Its drawback is that the initialization may be done multiple times if multiple threads access the initializer almost at the same time (however, it can be guaranteed that always the same object created by the initializer is returned).
> This is a proposal to add an {{AtomicInitializer}} class as an alternative to {{LazyInitializer}} that operates on {{AtomicReference}} variables.
> In order to make the initializers smoothly exchangable, it would make sense for them to share a common interface. This interface could also be implemented by the {{BackgroundInitializer}} class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.