RSDK-9588 - Always run updateWeakDependent within a lock #4645
Conversation
viambot
added
the
safe to test
| defer r.manager.resourceGraphLock.Unlock() | ||
| r.updateWeakDependents(ctx) | ||
| } | ||
|
|
||
| func (r *localRobot) updateWeakDependents(ctx context.Context) { |
There was a problem hiding this comment.
Why not lock and defer unlock of resourceGraphLock at the top of this method instead of introducing the InLock method? Are you trying not to lock when calling from completeConfig in the resource manager (call updateWeakDependents without a lock? If so, why?
There was a problem hiding this comment.
completeConfig already holds a resourceGraphLock so didn't think we should grab it again
There was a problem hiding this comment.
Cool; that's sort of what I assumed. I don't have a super strong opinion, but I would've thought that the completeConfig call to weak dependents would be the one that's "abnormal" in terms of method name: something like updateWeakDependentsWithoutLock, while the other call sites are just updateWeakDependents and take the lock.
But also, I'm more broadly concerned with just adding this locking in the first place, so see my other comment.
|
This was brought up offline briefly, but why are we adding extra locking here? It sounds like we haven't seen an issue wrt multiple |
generally want to make sure that we're not trying to reconfigure the same thing at the same time across different go routines. There are 4 calls to updateWeakDependents - New, Reconfigure, completeConfig loop, and removeOrphanedResources. Since there wasn't a lock before, they have a chance of calling updateWeakDependents all at the same time.
Using the resourceGraphLock because updateWeakDependents in the completeConfig loop already takes the resourceGraphLock