commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <>
Subject [jira] [Commented] (LANG-1086) Remove busy wait from AtomicSafeInitializer.get()
Date Wed, 25 Feb 2015 20:33:05 GMT


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}}
A small toolkit of classes that support lock-free thread-safe programming on single variables.

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.


> Remove busy wait from AtomicSafeInitializer.get()
> -------------------------------------------------
>                 Key: LANG-1086
>                 URL:
>             Project: Commons Lang
>          Issue Type: Improvement
>          Components: lang.concurrent.*
>            Reporter: Benedikt Ritter
>            Assignee: Benedikt Ritter
>              Labels: github
>             Fix For: 3.4
> Placeholder ticket for
> {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
> {quote}

This message was sent by Atlassian JIRA

View raw message