-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix data race in the suit #1165
fix data race in the suit #1165
Conversation
Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>
3ef114c
to
3b28e24
Compare
@boyan-soubachov PTAL |
another occurrence
|
@boyan-soubachov Hi~ Can you review it for us? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is your calling code trying to change the suite state concurrently? That seems to be the only way I can think of reproducing this problem.
Do you mind pasting some example code that would cause this issue?
suite/suite.go
Outdated
require *require.Assertions | ||
t *testing.T | ||
} | ||
|
||
// T retrieves the current *testing.T context. | ||
func (suite *Suite) T() *testing.T { | ||
suite.mu.Lock() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a read-only operation; I'm not sure it needs a mutex?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a sync.RWMutex
and suite.mu.RLock()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think it is a sync.RWMutex
.
Hi @boyan-soubachov I'm not familiar with go tests, for my case in #1165 (comment)
Can it be the the defer of |
opened an issue #1168 |
It is shown in the
|
the code of case in the PR body is this |
Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>
I think at least you can add an unit test as the comment above, and wait for the opinions of maintainers |
I guess it's caused by the wrong usage of the |
That's what I've stated in pingcap/tidb#26022 and #187 (comment). |
this quote is from #187 (comment). IMO if we want to achieve it, we should let main test goroutine in child test wait its spawned goroutine see my point of view in #1168 (comment) |
@boyan-soubachov PTAL |
The Read/Write mutexes are definitely an improvement, thanks! @lance6716 has a good point about an alternative where we require a pattern from the user but it doesn't seem intuitive or simple. I'm happy to proceed with @hawkingrei 's code. @lance6716 (and anyone else), any counter-opinions or thoughts on why we shouldn't go with the |
the RWMutex solution seems good to me 😄 |
Signed-off-by: Weizhen Wang wangweizhen@pingcap.com
Summary
we find a data race in the suit. so we think Mutex is added to the suit for solving it.
ref pingcap/tidb#32747
Changes
add Mutex to the suit.
Motivation
fix data race.
Related issues