You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "Craig Condit (Jira)" <ji...@apache.org> on 2023/12/01 12:42:00 UTC
[jira] [Comment Edited] (YUNIKORN-2223) Eliminate separate mutex variables
[ https://issues.apache.org/jira/browse/YUNIKORN-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17792033#comment-17792033 ]
Craig Condit edited comment on YUNIKORN-2223 at 12/1/23 12:41 PM:
------------------------------------------------------------------
Actually, there’s a very good reason not to do this. By eliminating the separate lock variable, you make the Lock() and Unlock() methods public. We really don’t want to do this, as that could lead to unforeseen deadlocks as locking is now available external to the object. I’m not in favor of this change.
was (Author: ccondit):
Actually, there’s a very good reason not to do this. By eliminating the separate lock variable, you make the Lock() and Unlock() methods public. We really don’t want to do this, as that could lead to unforeseen deadlocks locking is now available external to the object. I’m not in favor of this change.
> Eliminate separate mutex variables
> ----------------------------------
>
> Key: YUNIKORN-2223
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2223
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: shim - kubernetes
> Reporter: Peter Bacsko
> Priority: Minor
>
> In {{{}cache.Task{}}}, the lock variable is defined as:
> {noformat}
> type Task struct {
> ...
> schedulingState TaskSchedulingState
> sm *fsm.FSM
> lock *sync.RWMutex
> } {noformat}
> This also applies to {{cache.Application}} and {{cache.Context}}.
> In other parts of the code, we simply embed {{sync.RWMutex}}. There's no need to have a separate variable. Locking and unlocking become simpler.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org