Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 25 Feb 2015 21:08:06 +0000 (UTC)
From: "Arthur Naseef (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12776925.1424721458000.14754.1424898486264@Atlassian.JIRA>
In-Reply-To: <JIRA.12776925.1424721458000@Atlassian.JIRA>
References: <JIRA.12776925.1424721458000@Atlassian.JIRA>
 <JIRA.12776925.1424721458788@arcas>
Subject: [jira] [Commented] (LANG-1086) Remove busy wait from
 AtomicSafeInitializer.get()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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: 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)