[
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: [email protected]
For additional commands, e-mail: [email protected]
