commons-issues mailing list archives

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


Arthur Naseef commented on LANG-1086:

Reading the javadocs for the atomic package, compareAndSet is the atomic operation.  There
is a lock there, whether it is in java code, machine instructions or other.  Even if it's
not called a lock.  If no instructions can pass a point in the code until some event, that's
a lock.

Avoiding unstructured locks (i.e. unclear orders-of-operations with lock and unlock steps)
and large critical sections is very valuable in concurrent implementations.  Implementing
a concurrency toolset without locks - at some level - isn't possible.  Ultimately, there must
be some form of atomic "check-and-set" which means a lock; it could be a spinlock (busy-wait
with a mostly-guaranteed very short "spin" life), but it still operates as a lock.

In spite of any of this, the existing busy-wait solution is problematic.  Especially if the
initialize method throws an exception, leaving other threads busy-waiting indefinitely.

Oh, and does the LazyInitiaizer get a "pass" on the rules?  It's calling the initializer inside
a "synchronized' block.

> 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