[
https://issues.apache.org/jira/browse/LANG-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14337129#comment-14337129
]
Oliver Heger commented on LANG-1086:
------------------------------------
Maybe we have a problem with our terminology here. "Non-blocking" may be
misleading, so let's use the term "lock-free" as in the package description of
the {{java.util.concurrent.atomic}} package:
{quote}
A small toolkit of classes that support lock-free thread-safe programming on
single variables.
{quote}
It is the characteristic of the atomic initializers to be lock-free. Some
frameworks or programming models consider locks as evil. I would not go that
far, but I think the user guide for the {{concurrent}} package [1] describes
the different usage scenarios of the different initializers (and also their
dependency on specific use cases) pretty well. The point is that the library
offers a number of initializers with specific properties from which the
developer can choose the one that fits best. It may well be possible that for a
specific use case you are better off with writing your own initializer as we
cannot predict all possible scenarios.
My problem with this concrete patch is that a key characteristic of the
{{AtomicSafeInitializer}} class - being lock-free - is violated. And the reason
for this may simply be that case that it does not fit for the current usage
scenario.
[1]
http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/concurrent/package-summary.html#package_description
> Remove busy wait from AtomicSafeInitializer.get()
> -------------------------------------------------
>
> Key: LANG-1086
> URL: https://issues.apache.org/jira/browse/LANG-1086
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.concurrent.*
> Reporter: Benedikt Ritter
> Assignee: Benedikt Ritter
> Labels: github
> Fix For: 3.4
>
>
> Placeholder ticket for https://github.com/apache/commons-lang/pull/46
> {quote}
> Remove the busy wait from AtomicSafeInitializer.get().
> Also ensure waiting threads do not wait indefinitely after initialize()
> throws an exception, instead throwing the same exception, re-wrapped, for
> each requester.
> Brought the unit tests up to 100% coverage on AtomicSafeInitializer.
> Eliminated race condition on verifying at least one thread waiting for
> initialize() to complete in another thread.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
