Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 21 Sep 2017 17:34:00 +0000 (UTC)
From: "Wangda Tan (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.13098679.1504130746000.168541.1506015240157@Atlassian.JIRA>
In-Reply-To: <JIRA.13098679.1504130746000@Atlassian.JIRA>
References: <JIRA.13098679.1504130746000@Atlassian.JIRA> <JIRA.13098679.1504130746176@jira-lw-us.apache.org>
Subject: [jira] [Commented] (YARN-7135) Clean up lock-try order in common
 scheduler code
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 21 Sep 2017 17:34:05 -0000


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

Wangda Tan commented on YARN-7135:
----------------------------------

[~jojochuang], 

From Java doc: http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/Lock.html#lock()

{code} 
Implementation Considerations

A Lock implementation may be able to detect erroneous use of the lock, such as an invocation that would cause deadlock, and may throw an (unchecked) exception in such circumstances. The circumstances and the exception type must be documented by that Lock implementation.
{code}

Which means by design the ReentrantLock#lock won't throw any exception including unchecked, I'm +0 to this fix if it won't break anything.

> Clean up lock-try order in common scheduler code
> ------------------------------------------------
>
>                 Key: YARN-7135
>                 URL: https://issues.apache.org/jira/browse/YARN-7135
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: scheduler
>    Affects Versions: 3.0.0-alpha4
>            Reporter: Daniel Templeton
>            Assignee: weiyuan
>              Labels: newbie
>         Attachments: YARN-7135.001.patch, YARN-7135.002.patch, YARN-7135.003.patch
>
>
> There are many places that follow the pattern:{code}try {
>   lock.lock();
>   ...
> } finally {
>   lock.unlock();
> }{code}
> There are a couple of reasons that's a bad idea.  The correct pattern is:{code}lock.lock();
> try {
>   ...
> } finally {
>   lock.unlock();
> }{code}


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org