hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wei-Chiu Chuang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7135) Clean up lock-try order in common scheduler code
Date Thu, 21 Sep 2017 16:34:00 GMT

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

Wei-Chiu Chuang commented on YARN-7135:
---------------------------------------

[~v123582]
the patch does not apply against trunk. Since the scope of the patch is wide, this is not
unexpected. Please rebase the code and resubmit it.

[~leftnoteasy]
please correct me if I'm wrong. The fact that ReentrantLock.lock doesn't throw a checked exception
does not imply it does not throw except at all. Having the lock() outside try{} block looks
a good practice to me.

> 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


Mime
View raw message