[
https://issues.apache.org/jira/browse/LANG-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917205#action_12917205
]
Oliver Heger commented on LANG-609:
-----------------------------------
Maybe there is room for all of these variants?
{{AtomicInitializer}} as it is now may be appropriate for use cases where
multiple invocations of the {{initialize()}} method are not an issue. In such
scenarios it is the most efficient variant.
The code proposed here could be added as a new class, say
{{AtomicSafeInitializer}}. It has a bit more overhead, but guarantees the
one-time initialization.
I am not sure how this {{AtomicSafeInitializer}} compares to the
{{LazyInitializer}} implementation which is based on volatile variables and
synchronization. I assume it will be more efficient under low or moderate load.
If there are many thread trying to initialize the object concurrently, the
synchronization approach might be preferrable. But this certainly depends on
multiple factors, and users should do benchmarks in their concrete environment
before they take a decision.
So would you agree to add this code as a new {{AtomicSafeInitializer}} class?
Other preferences for the name?
> 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.
