Add test for possible race in guard condition notification#280
Add test for possible race in guard condition notification#280MiguelCompany wants to merge 3 commits into
Conversation
Signed-off-by: Miguel Company <miguelcompany@eprosima.com>
|
Tick the box to add this pull request to the merge queue (same as
|
…times Signed-off-by: Janosch Machowinski <J.Machowinski@cellumation.com>
|
Pulls: #280
|
|
Pulls: #280, ros2/rmw_fastrtps#895
|
| ASSERT_EQ(ret, RMW_RET_OK) << "Failed to receive any guard condition trigger"; | ||
|
|
||
| // Join the trigger thread | ||
| trigger_thread.join(); |
There was a problem hiding this comment.
if asserted, trigger_thread gets destroyed while joinable.
| ASSERT_EQ(ret, RMW_RET_OK) << "Failed to receive any guard condition trigger"; | |
| // Join the trigger thread | |
| trigger_thread.join(); | |
| // Join the trigger thread | |
| trigger_thread.join(); | |
| ASSERT_EQ(ret, RMW_RET_OK) << "Failed to receive any guard condition trigger"; |
| std::this_thread::sleep_for(std::chrono::milliseconds(10)); | ||
| for (size_t i = number_of_guard_conditions; i > 0; --i) { | ||
| rmw_ret_t ret = rmw_trigger_guard_condition(guard_condition_ptrs[i - 1]); | ||
| ASSERT_EQ(ret, RMW_RET_OK) << rcutils_get_error_string().str; |
There was a problem hiding this comment.
fatal assertions in a non-test thread only abort that thread's function, afaik.
probably better to record the return code and check it after join() in the main thread?
There was a problem hiding this comment.
I think using EXPECT_EQ would be enough
| guard_conditions.guard_conditions[j] = guard_condition_ptrs[j]->data; | ||
| } | ||
|
|
||
| // Thread that triggers all guard conditions in reverse order after 100ms |
There was a problem hiding this comment.
typo?
| // Thread that triggers all guard conditions in reverse order after 100ms | |
| // Thread that triggers all guard conditions in reverse order after 10ms |
Signed-off-by: Miguel Company <miguelcompany@eprosima.com>
3 participants
Description
Adds a test that checks that notifying 10 guard conditions from one thread while using
rmw_waitin another thread makes all conditions be notified exactly once.Is this user-facing behavior change?
Did you use Generative AI?
Additional Information
Due to the flaky nature of race conditions, the test shall be run with
--ctest-args --repeat until-fail:10to make it fail