[
https://issues.apache.org/jira/browse/YUNIKORN-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17792042#comment-17792042
]
Craig Condit commented on YUNIKORN-2223:
----------------------------------------
In the core, I believe most of the instances occur within the same package, and
so the access control is roughly equivalent since all code in the same package
has access to private members. Personally, I’m not a fan of the anonymous use.
It means that, if the object is public, the locking becomes public as well.
That’s just an anti-pattern. IMO, anonymous lock objects should only occur in
privately-named objects. As for the discrepancy, chalk it up to different
authors and different styles.
> 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: [email protected]
For additional commands, e-mail: [email protected]
