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

Varun Saxena edited comment on YARN-3142 at 9/22/16 8:30 PM:
-------------------------------------------------------------

Thanks [~leftnoteasy], [~sunilg] for reviews. 

bq. Lock is not required
Right. Will fix.

bq. You may need to synchronize placesBlacklistedByApp and call 
placesBlacklistedByApp.addAll(appInfo.getBlackList()) to make it consistent to 
other blacklist-related operations.
But we wont be using this till we set current attempt in scheduler which is 
after this. Also, this is a reference assignment which is atomic. Thoughts ?

bq. (Imaging someone replace the request in another thread before returning)
You mean remove the request from the resource request map ? Well the part about 
fetching from resource request map i.e. call to getResourceRequest is within 
locks. After that we just access ResourceRequest instance. And capability which 
we are returning here wont be changed even by another thread. However this is 
is not immutable field so we can probably guard it with a read lock just to be 
safe. Thoughts ?


was (Author: varun_saxena):
Thanks [~leftnoteasy], [~sunilg] for reviews. 

bq. Lock is not required
Right. Will fix.

bq. You may need to synchronize placesBlacklistedByApp and call 
placesBlacklistedByApp.addAll(appInfo.getBlackList()) to make it consistent to 
other blacklist-related operations.
But we wont be using this till we set current attempt in scheduler which is 
after this. Also, this is a reference assignment which is atomic. Thoughts ?

bq. (Imaging someone replace the request in another thread before returning)
You mean remove the request from the resource request map. Well the part about 
fetching from resource request map i.e. call to getResourceRequest is within 
locks. After that we just access ResourceRequest instance. And capability which 
we are returning here wont be changed even by another thread. However this is 
is not immutable field so we can probably guard it with a read lock just to be 
safe. Thoughts ?

> Improve locks in AppSchedulingInfo
> ----------------------------------
>
>                 Key: YARN-3142
>                 URL: https://issues.apache.org/jira/browse/YARN-3142
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager, scheduler
>            Reporter: Wangda Tan
>            Assignee: Varun Saxena
>         Attachments: YARN-3142.01.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to