-
Notifications
You must be signed in to change notification settings - Fork 4k
ARROW-13223: [C++] Fix Thread Sanitizer test failures #10632
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -15,6 +15,7 @@ | |
| // specific language governing permissions and limitations | ||
| // under the License. | ||
|
|
||
| #include <atomic> | ||
| #include <chrono> | ||
| #include <condition_variable> | ||
| #include <mutex> | ||
|
|
@@ -68,14 +69,14 @@ class TrackingGenerator { | |
| return state_->source(); | ||
| } | ||
|
|
||
| int num_read() { return state_->num_read; } | ||
| int num_read() { return state_->num_read.load(); } | ||
|
|
||
| private: | ||
| struct State { | ||
| explicit State(AsyncGenerator<T> source) : source(std::move(source)), num_read(0) {} | ||
|
|
||
| AsyncGenerator<T> source; | ||
| int num_read; | ||
| std::atomic<int> num_read; | ||
|
||
| }; | ||
|
|
||
| std::shared_ptr<State> state_; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -824,7 +824,10 @@ tasks: | |
| template: docker-tests/github.linux.yml | ||
| params: | ||
| env: | ||
| # clang-tools and llvm version need to be synchronized so as | ||
| # to have the right llvm-symbolizer version | ||
| CLANG_TOOLS: 11 | ||
| LLVM: 11 | ||
|
||
| UBUNTU: 20.04 | ||
| image: ubuntu-cpp-thread-sanitizer | ||
|
|
||
|
|
||
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.
Of course, we could also not bother with this complication, since
worker_thread_idis only used for debugging.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.
True, but the assert catches an otherwise potentially subtle issue in how BackgroundGenerator is meant to be used. It's not entirely obvious that you aren't allowed to dispose of it from the worker thread and it a fair amount of debugging to discover this root cause.
What was the issue? Is it because the worker thread id might be changing (from set to unset) when the assert in cleanup happens?
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.
Exactly, yes.
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.
If this neat trick to turn a
thread::idinto anint64_tis indeed reliable it might be nice to addint64_t arrow::internal::GetCurrentThreadId(). Probably inthread_pool.h/cc.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.
Will do.
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.
See #10644