Skip to content
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

[TEST] Skip parallel tests on machines having a single CPU #3303

Merged
merged 1 commit into from
Nov 11, 2024

Conversation

sanvila
Copy link
Contributor

@sanvila sanvila commented Nov 11, 2024

Otherwise this is what happens:

The following tests FAILED:
        5762 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.spmc_sum (Failed)
        5763 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpsc_sum (Failed)
        5764 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpmc_sum (Failed)
        5767 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.spmc_dynamicsize (Failed)
        5768 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.spmc_fixedsize (Failed)
        5769 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpsc_dynamicsize (Failed)
        5770 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpsc_fixedsize (Failed)
        5771 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpmc_dynamicsize (Failed)
        5772 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpmc_fixedsize (Failed)
Errors while running CTest

@seqan-actions seqan-actions added lint [INTERNAL] signal for linting and removed lint [INTERNAL] signal for linting labels Nov 11, 2024
@seqan-actions
Copy link
Member

Documentation preview available at https://docs.seqan.de/preview/seqan/seqan3/3303

@seqan-actions seqan-actions added lint [INTERNAL] signal for linting and removed lint [INTERNAL] signal for linting labels Nov 11, 2024
@sanvila sanvila changed the title Skip parallel tests on machines having a single CPU [TEST] Skip parallel tests on machines having a single CPU Nov 11, 2024
Copy link

codecov bot commented Nov 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.13%. Comparing base (3b4f644) to head (54e011d).
Report is 2 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3303   +/-   ##
=======================================
  Coverage   98.13%   98.13%           
=======================================
  Files         271      271           
  Lines       11948    11948           
  Branches      104      104           
=======================================
  Hits        11725    11725           
  Misses        223      223           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@eseiler
Copy link
Member

eseiler commented Nov 11, 2024

Hey @sanvilla,

thanks for the PR!

As this bug results from dividing the thread count by two in

size_t writer_count = thread_count / 2;

I would suggest adapting the test instead

diff --git a/test/unit/contrib/parallel/buffer_queue_parallel_test.cpp b/test/unit/contrib/parallel/buffer_queue_parallel_test.cpp
index 6bf5b553e..34c8def1a 100644
--- a/test/unit/contrib/parallel/buffer_queue_parallel_test.cpp
+++ b/test/unit/contrib/parallel/buffer_queue_parallel_test.cpp
@@ -15,11 +15,8 @@
 template <typename sequential_push_t, typename sequential_pop_t>
 void test_buffer_queue_wait_status()
 {
-    size_t thread_count = std::thread::hardware_concurrency();
-
-    // limit thread count as virtualbox (used by Travis) seems to have problems with thread congestion
-    if (thread_count > 4)
-        thread_count = 4;
+    // At least two threads (one producer and one consumer), at most 4 threads (avoid congestion).
+    size_t thread_count = std::clamp<size_t>(std::thread::hardware_concurrency(), 2u, 4u);
 
     size_t writer_count = thread_count / 2;
     if constexpr (sequential_push_t::value)
@@ -129,11 +126,9 @@ void test_buffer_queue_wait_throw(size_t initialCapacity)
     }
 
     volatile std::atomic<size_t> chk_sum2 = 0;
-    size_t thread_count = std::thread::hardware_concurrency();
 
-    // limit thread count as virtualbox (used by Travis) seems to have problems with thread congestion
-    if (thread_count > 4)
-        thread_count = 4;
+    // At least two threads (one producer and one consumer), at most 4 threads (avoid congestion).
+    size_t thread_count = std::clamp<size_t>(std::thread::hardware_concurrency(), 2u, 4u);
 
     size_t writer_count = thread_count / 2;
     if constexpr (sequential_push_t::value)

Do you want to adapt your PR or should we push the changes?

@SGSSGene
Copy link
Contributor

@sanvila : What you have found, is definitely a bug in our tests. But, I am curious, under which circumstances do you actually have only one core?

@SGSSGene SGSSGene added the bug faulty or wrong behaviour of code label Nov 11, 2024
@sanvila
Copy link
Contributor Author

sanvila commented Nov 11, 2024

Do you want to adapt your PR or should we push the changes?

Feel free to reject the PR and fix the issue as you see fit, as long as it works on single-CPU systems.

Thanks a lot!

Otherwise this is what happens:

The following tests FAILED:
        5762 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.spmc_sum (Failed)
        5763 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpsc_sum (Failed)
        5764 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpmc_sum (Failed)
        5767 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.spmc_dynamicsize (Failed)
        5768 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.spmc_fixedsize (Failed)
        5769 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpsc_dynamicsize (Failed)
        5770 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpsc_fixedsize (Failed)
        5771 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpmc_dynamicsize (Failed)
        5772 - contrib/parallel/buffer_queue_parallel_test::buffer_queue.mpmc_fixedsize (Failed)
Errors while running CTest
@eseiler eseiler requested a review from SGSSGene November 11, 2024 21:16
@eseiler eseiler enabled auto-merge November 11, 2024 21:16
@seqan-actions seqan-actions added lint [INTERNAL] signal for linting and removed lint [INTERNAL] signal for linting labels Nov 11, 2024
Copy link
Contributor

@SGSSGene SGSSGene left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thx!

@eseiler eseiler merged commit 89cc4d3 into seqan:main Nov 11, 2024
42 checks passed
@sanvila
Copy link
Contributor Author

sanvila commented Nov 11, 2024

What you have found, is definitely a bug in our tests. But, I am curious, under which circumstances do you actually have only one core?

Good question! I'm doing QA work for Debian, using virtual machines in the cloud, to ensure that all packages may be built from source.

The official Debian autobuilders are physical machines with four or more CPUs, and as a result, that’s the most tested configuration. So, to compensate, I’m using systems with one and two CPUs for my QA work. After all, Debian aims to be the universal operating system, suitable for both desktops and servers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug faulty or wrong behaviour of code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants