Conversation
to catch false positives in newer version of scoped_threadpool
this change is required to prevent this snippet triggering a TSAN error (data race)
in debug & release mode
``` rust
// scoped_threadpool = "0.1.9"
use scoped_threadpool::Pool;
fn main() {
Pool::new(2).scoped(move |scope| {
scope.execute(move || {});
scope.execute(move || {});
});
}
```
Member
Author
|
the supressions seem to be too heavy handed. this triggers a data race as expected (debug profile) use std::thread;
static mut X: i32 = 0;
let t1 = thread::spawn(|| unsafe { ptr::addr_of_mut!(X).write_volatile(1) });
unsafe {
ptr::addr_of_mut!(X).write_volatile(2);
}
t1.join().ok();with the above supressions, this does NOT trigger a data race Pool::new(2).scoped(move |scope| {
for i in 0..2 {
scope.execute(move || unsafe { ptr::addr_of_mut!(X).write_volatile(i) });
}
});without the supressions file, the false positives seem to mask the real data race because the variable it may be best to remove the |
japaric
added a commit
that referenced
this pull request
Apr 29, 2022
as it's easier to deal with TSAN false positives in the former API as surfaced in PR 280 the current supression rules don't handle newer versions of the scoped_threadpool crate trying to update the supression rules related to scoped_threadpool in PR #282 revealed that the supression rules are masking (hiding) real data races: #282 (comment) std::thread::scope requires less supression rules and does not mask real data races -- for instance, the data race in the linked issue comment is not masked when using std::thread::scope tradeoffs: - pro: one less dev dependency - pro: supressions file is simpler - cons: std::thread::scope is only available on recent nightlies
japaric
added a commit
that referenced
this pull request
Apr 29, 2022
as it's easier to deal with TSAN false positives in the former API as surfaced in PR 280 the current supression rules don't handle newer versions of the scoped_threadpool crate trying to update the supression rules related to scoped_threadpool in PR #282 revealed that the supression rules are masking (hiding) real data races: #282 (comment) std::thread::scope requires less supression rules and does not mask real data races -- for instance, the data race in the linked issue comment is not masked when using std::thread::scope tradeoffs: - pro: one less dev dependency - pro: supressions file is simpler - cons: std::thread::scope is only available on recent nightlies
Member
Author
|
closing in favor of PR #283 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
to catch false positives in newer version of scoped_threadpool
this change is required to prevent this snippet triggering a TSAN error (data race)