Cheung, B, Wang, CL, Ma, MJM et al. · The HKU Scholars Hub (University of Hong Kong) · 2010
To achieve single system image (SSI) for cluster computing is a challenging task since SSI is a form of complete transparency that requires the integration and unification of all types of resources in a cluster.In this paper, we propose a new Java computing platform with the concept of Single Thread Space, which is a true parallel computing environment for performing a multi-threaded Java application on a cluster environment.Threads running within this space would share all the resources that each thread has created or allocated and they view the underlying cluster as a single computing system.We realize the single thread space based on a middleware developed at a virtual machine level, which allows application program to create as many threads as needed.The middleware can automatically distribute the executing threads across the cluster to exploit the maximal parallelism and to optimize the overall resource utilization.The implementation is compatible with the standard JVM and does not need any low-level or platform-specific supports.Thus it is portable across different hardware platforms.
Cited by 0Open access
Torsten Hoefler, Andrew Lumsdaine · 2008
Message progression schemes that enable communication and computation to be overlapped have the potential to improve the performance of parallel applications. With currently available high-performance networks there are several options for making progress: manual progression, use of a progress thread, and communication offload. In this paper we analyze threaded progression approaches, comparing the effects of using shared or dedicated CPU cores for progression. To perform these comparisons, we propose time-based and work-based benchmark schemes. As expected, threaded progression performs well when a spare core is available to be dedicated to communication progression, but a number of operating system effects prevent the same benefits from being obtained when communication progress must share a core with computation. We show that some limited performance improvement can be obtained in the shared-core case by real-time scheduling of the progress thread.
Cited by 101
Kelvin Kin Fan Chong · 2005
Cited by 0
Zhenfu Feng, Huan Zhang, Lidong Xing et al. · 2024
A power-efficient Single Instruction Multiple Threads (SIMT) processor is proposed to address the increasing demands of high-performance computing in graphics rendering media processing, artificial intelligence etc... The processor supports thread-level parallelism by managing multiple threads into WARPS. The specific work includes the following aspects: 1) merge a common five-stage pipeline structure with an emission stage to form a low latency memory access structure; 2) an independent RISC instruction set; 3) two-level WARP scheduling algorithm for highly efficient thread management; 4) functional validation and performance evaluation were conducted on the overall implementation. The results indicate that the processor achieves optimal performance when the number of PEs equals to the matrix dimension on GEMM task. Furthermore, the architecture shows super linear speedup capability when the number of PE cores is less than 32. The performance grows continuously as the number of PE cores, but the decreased growth rate is observed.
Cited by 0
Shuo Wang, Lei Wang · 2006
Presented in this paper is the thread-associative memory microarchitecture for multicore and multithreaded processor design. Memory contention among concurrent threads in chip multithreaded processing has become a limiting factor for performance improvement. The proposed thread-associative memory addresses this challenge by incorporating thread-specific information explicitly into on-chip memory hardware. The proposed technique can be utilized at different levels of memory hierarchy. Furthermore, it is not just a technique for performance enhancement but also a solution for energy efficiency. Trace-driven simulations on a 32KB L1 data cache demonstrate 36.6% maximum performance improvement and up to 15.1% total energy reduction, with 20.3% dynamic energy reduction and 9.9% leakage energy reduction.
Cited by 7
Boixaderas Coderch, Isaac · RECERCAT (Consorci de Serveis Universitaris de Catalunya) · 2015
[CATALÀ] Aquest projecte proposa una manera de detectar si existeixen diferències significatives entre els threads involucrats en l'execució d'una aplicació de "hihg-performance computing (HPC)", així com també un algorisme eficient per agrupar els threads en funció de les seves diferències.
Cited by 0Open access
Z.A. OVCHAROV · Herald Of Technological University · 2023
This paper discusses methods for optimizing computations performed in a client-side browser. It is shown that one of the main problems of organizing computations on the client side (the so-called "thick" client) is the slowdown of its work and blocking due to the single-threadedness of the computational kernel of standard browsers based on JavaScript. To overcome the identified disadvantages of such organization of the "thick" client it is proposed to use two approaches based on additional systems embedded in the browser: Web Workers and Web Assembler. The review of both of these methods of "thick" client optimization is given. The Web Workers system allows parallelizing computation processes by running computational scripts in the background thread of execution. The parallel and main execution threads exchange data in both directions by means of an event pattern. The Web Assembler system also allows you to create a parallel thread of computation by using a virtual code execution machine. The executable code can be written in any programming language. The theoretical hypotheses about acceleration of computations and reduction of blocking time when using the two mechanisms considered in the paper are confirmed by computational experiments on parallelization of the task of intersection search on a set of HTML elements of a web page. Both approaches showed improved performance on both comparison criteria compared to the traditional JavaScript code-based approach. The gains in computation time and blocking time increased linearly with the size of the processed data. It is shown that the considered approaches can be used for any logic of "thick" client web-applications implementation, where it is required to perform a large number of calculations on the client side under the existing limitations of the execution environment.
Cited by 0
Angger Abdul Razak, Adharul Muttaqin, Erza Erza Pradipta · Jurnal EECCIS (Electrics Electronics Communications Controls Informatics Systems) · 2022
GPU computing dapat mempersingkat waktu eksekusi suatu aplikasi yang sebelumnya dianggap memakan waktu eksekusi yang lama dengan memanfaatkan pemrograman paralel. Penerapan multi-GPU memungkinkan untuk meningkatkan performa lebih lanjut dalam menjalankan pemrograman paralel tersebut. Namun, tidak semua program berlaku demikian. Salah satu aplikasi yang membutuhkan pemrograman secara paralel adalah image denoising. Untuk melihat apakah apakah penggunaan multi-GPU dapat menambah performa program image denoising, analisis dari pembatasan jumlah thread terhadap waktu eksekusi, penggunaan daya, dan memori GPU dapat diterapkan pada single GPU. Apabila pembatasan thread menurunkan performa program image denoising secara signifikan, maka penggunaan multi-GPU menjadi kandidat untuk meningkatkan performa lebih tinggi. Dalam penelitian ini, perancangan pembatasn thread diimplementasikan dengan proses looping pada bagian kernel program image denoising yang menggunakan filter KNN (K-Nearest Neighbors) dan NLM (Non Local Means). Hasil penelitian ini menunjukan pada penggunaan thread di bawah 5% pada filter KNN dan thread 0,01% pada filter NLM menghasilkan konsumsi daya dan waktu eksekusi yang optimal. Selain itu, pada penggunaan thread di atas 5% pada filter KNN maupun NLM tidak ditemukan perubahan performa yang signifikan, sehingga penambahan performa pada program image denoising akan minimal dengan penerapan sistem multi GPU.
Cited by 1Open access
Holger Blaar, M. Legeler, Thomas Rauber · 2002
Many applications from scientific computing can benefit from object-oriented programming techniques because of their flexible and modular program development support. On the other hand, acceptable execution time can often only be reached by using a parallel machine. We investigate the support of Java for parallel execution. By using Java's thread mechanism we study how basic numerical methods can be expressed in parallel and which overhead is caused by thread management. We consider implementations that differ in scheduling, synchronization, and the management of threads. We obtain some guidelines to organize a multithreaded Java program to get best performance.
Cited by 5
Holger Blaar Matthias, Matthias Legeler, Thomas Rauber · 2002
from object-oriented programming techniques because of their flexible and modular program development support. On the other hand, acceptable execution time can often only be reached by using a parallel machine. We investigate the support of Java for parallel execution. By using Java's thread mechanism we study how basic numerical methods can be expressed in parallel and which overhead is caused by thread management. We consider implementations that differ in scheduling, synchronization, and the management of threads. We obtain some guidelines to organize a multithreaded Java program to get best performance.
Cited by 0
Krishna K. Rangan, Gu-Yeon Wei, David Brooks · 2009
Dynamic voltage and frequency scaling (DVFS) is a commonly-used power-management scheme that dynamically adjusts power and performance to the time-varying needs of running programs. Unfortunately, conventional DVFS, relying on off-chip regulators, faces limitations in terms of temporal granularity and high costs when considered for future multi-core systems. To overcome these challenges, this paper presents thread motion (TM), a fine-grained power-management scheme for chip multiprocessors (CMPs). Instead of incurring the high cost of changing the voltage and frequency of different cores, TM enables rapid movement of threads to adapt the time-varying computing needs of running applications to a mixture of cores with fixed but different power/performance levels. Results show that for the same power budget, two voltage/frequency levels are sufficient to provide performance gains commensurate to idealized scenarios using per-core voltage control. Thread motion extends workload-based power management into the nanosecond realm and, for a given power budget, provides up to 20% better performance than coarse-grained DVFS.
Cited by 207
Ivan Komarov (120593), Roshan M. D'Souza (120596) · Figshare · 2015
<p>The basic execution unit is a thread. Threads are grouped into thread blocks. Each thread block is executed on a single multi-processor. Threads in a thread block can communicate through shared memory which is essentially a user-controlled cache. In the latest GPUs, shared memory can be configured to act as an L1 cache. Register space can be used to store data local to threads with the fastest access speed. Spill-over data that does not fit in registers goes to local memory, which is physically stored in the main memory and which is very slow. Main memory has three components. Global memory is accessible to all threads and is cached through an L2 cache that is shared among all multi-processors on the latest generation GPUs. Constant memory is typically used to store data that is used by all threads (simulation constants) and that is automatically cached. Texture memory is read-only memory with automatic cache.</p>
Cited by 0Open access
Díaz-Martín, Juan-Carlos, Rico-Gallego, Juan-Antonio · e-Archivo (Carlos III University of Madrid) · 2015
Proceedings of: First International Workshop on Sustainable Ultrascale Computing Systems (NESUS 2014). Porto (Portugal), August 27-28, 2014.
Cited by 0Open access
David Tam, Reza Azimi, Michael Stumm · ACM SIGOPS Operating Systems Review · 2007
The major chip manufacturers have all introduced chip multiprocessing (CMP) and simultaneous multithreading (SMT) technology into their processing units. As a result, even low-end computing systems and game consoles have become shared memory multiprocessors with L1 and L2 cache sharing within a chip. Mid- and large-scale systems will have multiple processing chips and hence consist of an SMP-CMP-SMT configuration with non-uniform data sharing overheads. Current operating system schedulers are not aware of these new cache organizations, and as a result, distribute threads across processors in a way that causes many unnecessary, long-latency cross-chip cache accesses. In this paper we describe the design and implementation of a scheme to schedule threads based on sharing patterns detected online using features of standard performance monitoring units (PMUs) available in today's processing units. The primary advantage of using the PMU infrastructure is that it is fine-grained (down to the cache line) and has relatively low overhead. We have implemented our scheme in Linux running on an 8- way Power5 SMP-CMP-SMT multi-processor. For commercial multithreaded server workloads (VolanoMark, SPECjbb, and RUBiS), we are able to demonstrate reductions in cross-chip cache accesses of up to 70%. These reductions lead to application-reported performance improvements of up to 7%.
Cited by 52
Shaz Qadeer · 2003
SRC’s charter is to advance the state of the art in computer systems by doing basic and applied research in support of our company’s business objectives. Our interests and projects span scalable systems (including hardware, networking, distributed systems, and programming-language technology), the Internet (including the Web, e-commerce, and information retrieval), and human/computer interaction (including user-interface technology, computer-based appliances, and mobile computing). SRC was established in 1984 by Digital Equipment Corporation. We test the value of our ideas by building hardware and software prototypes and assessing their utility in realistic settings. Interesting systems are too complex to be evaluated solely in the abstract; practical use enables us to investigate their properties in depth. This experience is useful in the short term in refining our designs and invaluable in the long term in advancing our knowledge. Most of the major advances in information systems have come through this approach, including personal computing, distributed systems, and the Internet. We also perform complementary work of a more mathematical character. Some
Cited by 0
Journal Irjcs, Doshi Fenil R., Pooniwala Rohan H. et al. · 2016
Cited by 0
Shoshany, Barak · Zenodo (CERN European Organization for Nuclear Research) · 2021
<code>BS_thread_pool.hpp</code>: Main <code>BS::thread_pool</code> class: Added a new member function, <code>push_loop()</code>, which does the same thing as <code>parallelize_loop()</code>, except that it does not return a <code>BS::multi_future</code> with the futures for each block. Just like <code>push_task()</code> vs. <code>submit()</code>, this avoids the overhead of creating the futures, but the user must use <code>wait_for_tasks()</code> or some other method to ensure that the loop finishes executing, otherwise bad things will happen. <code>push_task()</code> and <code>submit()</code> now utilize perfect forwarding in order to support more types of tasks - in particular member functions, which in previous versions could not be submitted unless wrapped in a lambda. To submit a member function, use the syntax <code>submit(&class::function, &object, args)</code>. More information can be found in <code>README.md</code>. See #9. <code>push_loop()</code> and <code>parallelize_loop()</code> now have overloads where the first argument (the first index in the loop) is omitted, in which case it is assumed to be 0. This is for convenience, as the case where the first index is 0 is very common. Helper classes: <code>BS::synced_stream</code> now utilizes perfect forwarding in the member functions <code>print()</code> and <code>println()</code>. Previously, it was impossible to pass the flushing manipulators <code>std::endl</code> and <code>std::flush</code> to <code>print()</code> and <code>println()</code>, since the compiler could not figure out which template specializations to use. The new objects <code>BS::endl</code> and <code>BS::flush</code> are explicit casts of these manipulators, whose sole purpose is to enable passing them to <code>print()</code> and <code>println()</code>. <code>BS::multi_future::get()</code> now rethrows exceptions generated by the futures, even if the futures return <code>void</code>. See #62. Added a new helper class, <code>BS::blocks</code>, which is used by <code>parallelize_loop()</code> and <code>push_loop()</code> to divide a range into blocks. This class is not documented in <code>README.md</code>, as it most likely will not be of interest to most users, but it is still publicly available, in case you want to parallelize something manually but still benefit from the built-in algorithm for splitting a range into blocks. <code>BS_thread_pool_test.cpp</code>: Added plenty of new tests for the new features described above. Fixed a bug in <code>count_unique_threads()</code> that caused it to get stuck on certain systems. <code>dual_println()</code> now also flushes the stream using <code>BS::endl</code>, so that if the test gets stuck, the log file will still contain everything up to that point. (Note: It is a common misconception that <code>std::endl</code> and <code>'\n'</code> are interchangeable. <code>std::endl</code> not only prints a newline character, it also flushes the stream, which is not always desirable, as it may reduce performance.) The performance test has been modified as follows: Instead of generating random vectors using <code>std::mersenne_twister_engine</code>, which proved to be inconsistent across different compilers and systems, the test now generates each element via an arbitrarily-chosen numerical operation. In my testing, this provided much more consistent results. Instead of using a hard-coded vector size, a suitable vector size is now determined dynamically at runtime. Instead of using <code>parallelize_loop()</code>, the test now uses the new <code>push_loop()</code> function to squeeze out a bit more performance. Instead of setting the test parameters to achieve a fixed single-threaded mean execution time of 300 ms, the test now aims to achieve a fixed multi-threaded mean execution time of 50 ms when the number of blocks is equal to the number of threads. This allows for more reliable results on very fast CPUs with a very large number of threads, where the mean execution time when using all the threads could previously be below a statistically significant value. The number of vectors is now restricted to be a multiple of the number of threads, so that the blocks are always all of the same size. <code>README.md</code>: Added instructions and examples for the new features described above. Rewrote the documentation for <code>parallelize_loop()</code> to make it clearer.
Cited by 0Open access
Shoshany, Barak · Zenodo (CERN European Organization for Nuclear Research) · 2024
v5.0.0 (2024-12-19) A major new release with many new features, improvements, bug fixes, and performance optimizations! Please note that code written using previous releases may need to be modified to work with the new release. The changes needed to migrate to the new API are explicitly indicated below for your convenience. Highlights: Added support for C++20 and C++23, while maintaining full C++17 compatibility. In C++20, the library can now optionally be imported as a module using import BS.thread_pool on Clang, GCC, and MSVC. In C++23, both the library itself and the test program can now optionally import the C++ Standard Library as a module using import std on supported compilers and platforms. Extensive documentation has been added to README.md on how to use these features, to ease the transition. Optional features are now enabled via a bitmask template parameter instead of macros, using the flags BS::tp::priority, BS::tp::pause, and BS::tp::wait_deadlock_checks. This makes the optional features easier to use, allows multiple thread pools with different features to coexist, and makes the library compatible with C++20 modules. Exception handling is now disabled automatically if exceptions are disabled, instead of using a macro. Added optional native extensions for non-portable features using the operating system's native API: setting the priority and affinity for processes and threads, and setting thread names. These have been tested on the latest versions of Windows, Ubuntu, and macOS. This library is now back to being a true single-header library, with a single header file BS_thread_pool.hpp. The utility classes have been combined into the main header file. BS::timer has been removed, BS::signaller has been replaced with BS::binary_semaphore and BS::counting_semaphore (in C++17 mode only), and BS::synced_stream now supports multiple output streams. Cleanup functions can now be defined to complement the initialization functions. Both initialization and cleanup functions can now optionally take the index of the thread as an argument. Parallelization member functions no longer need type casting or template parameters if the start and end indices are of different types. The worker function no longer incorrectly reads shared variables while the mutex is unlocked. The type aliases BS::this_thread::optional_index and BS::this_thread::optional_pool have been removed. Instead, BS::this_thread::get_index() returns std::optional<std::size_t>, and BS::this_thread::get_pool() returns std::optional<void*>. The latter must be cast to the correct instantiation of the BS::thread_pool class template before using any member functions. The thread pool version is now accessible using the object BS::thread_pool_version, a constexpr struct of type BS::version with the members major, minor, and patch. This works even if importing the library as a C++20 module, unlike the version macros. The type priority_t, used to set priorities, is now defined as std::int8_t, which means it takes values from -128 to +127. The pre-defined priorities in BS::pr, such as BS::pr::highest or BS::pr::lowest, have been updated accordingly. Exceptions thrown by detached tasks are now caught and prevented from propagating, so that they do not terminate the program. Exceptions thrown by submitted tasks are still rethrown when calling get() on the future, as before. Parallelization member functions no longer destruct objects prematurely under certain circumstances. The test program has been expanded with many new tests for both old and new features. It can also import both the thread pool module using import BS.thread_pool (in C++20 and later) and the C++ Standard Library module using import std (in C++23) if the appropriate macros are defined, and read default command line arguments from a default_args.txt file for debugging purposes. Added new and improved benchmarks using a highly-optimized multithreaded algorithm which generates a plot of the Mandelbrot set, utilizing a normalized iteration count algorithm and linear interpolation to create smooth coloring. The type BS::concurrency_t has been removed; use std::size_t instead. C++20 and C++23 support: This library now officially supports C++20 and C++23 in addition to C++17. If compiled with C++20 and/or C++23 support (e.g. using the compiler flag -std=c++23 in Clang/GCC or /std:c++latest on MSVC), the library will make use of newly available features for maximum performance, reliability, and usability. To be clear, the library is still fully compatible with any C++17 standard-compliant compiler. I have no plans to remove C++17 support at the moment, as it is still the most widely used C++ standard among developers, but that might change in the future. If C++20 features are available, the library can be imported as a module using import BS.thread_pool. This is now the officially recommended way to use the library, as it has many benefits, such as faster compilation times, better encapsulation, no namespace pollution, no include order issues, easier maintainability, simpler dependency management, and more. The module file itself is BS.thread_pool.cppm, located in the modules folder, and it is just a thin wrapper around the header file BS_thread_pool.hpp. The constexpr flag BS::thread_pool_module indicates whether the thread pool library was compiled as a module. To my knowledge, BS::thread_pool is one of the only popular C++ libraries that are currently available as a C++20 module (and certainly the only thread pool library). This feature has been tested with the latest versions of Clang, GCC, and MSVC. Unfortunately, C++20 modules are still (4 years later!) not fully implemented in all compilers, and each compiler implements them differently; for instructions on how to compile and import the BS.thread_pool module in each compiler, please see README.md. Known issues: GCC v14.2.0 (latest version at the time of writing) appears to have an internal compiler error when compiling programs containing modules (or at least, this particular module) with any optimization flags other than -Og enabled. Until this is fixed, if you wish to use compiler optimizations, please either include the library as a header file or use a different compiler. On macOS, Apple Clang v16.0.0 (latest version at the time of writing) does not support C++20 modules. Please either install the latest version of LLVM Clang using Homebrew, or include the library as a header file. Visual Studio Code's C/C++ extension v1.23.2 (latest version at the time of writing) does not yet support modules. My temporary solution for that, as demonstrated in the test program, is to define the macro BS_THREAD_POOL_TEST_IMPORT_MODULE (see below) when compiling the test program, but not when editing in the IDE. If the macro is enabled, the module is imported via import BS.thread_pool, otherwise the header file is included using #include "BS_thread_pool.hpp" as usual. If C++23 features are available, both the library and the test program can now import the C++ Standard Library as a module using import std. To enable this, define the macro BS_THREAD_POOL_IMPORT_STD at compilation time. This is currently only officially supported by recent versions of MSVC with Microsoft STL or LLVM Clang (not Apple Clang) with LLVM libc++. It is not supported by GCC with any standard library, Clang with any standard library other than libc++, any compiler with GNU libstdc++, or any other compiler. If BS_THREAD_POOL_IMPORT_STD is defined, then you must also import the library itself as a module. If the library is included as a header file, this will force the program that included the header file to also import std, which is not desirable and can lead to compilation errors if the program #includes any Standard Library header files. Defining the macro before importing the module will not work, as modules cannot access macros defined in the program that imported them. Instead, define the macro as a compiler flag, e.g. -D BS_THREAD_POOL_IMPORT_STD (or /D for MSVC). The constexpr flag BS::thread_pool_import_std indicates whether the thread pool library was compiled with import std. Note that the flag will be false if BS_THREAD_POOL_IMPORT_STD is defined but the compiler or standard library does not support importing the C++ Standard Library as a module. If C++20 features are available, the pool will use std::jthread instead of std::thread. This allows considerable simplification and added safety, since the threads no longer need to be manually joined, and std::stop_token is used to stop the workers automatically when destructing the threads. This eliminates the need for the destroy_threads() member function, as well as the workers_running flag, which are now only used in C++17 mode. If C++20 features are available, the library will use concepts to enforce the signature of the initialization function and to selectively enable member functions related to pausing only if pausing is enabled. In C++17 mode, the library will use SFINAE to achieve essentially the same effect. If C++23 features are available, the task queue will use std::move_only_function<void()> instead of std::function<void()>. This allows submit_task() to work without using a shared pointer, which should increase performance. API migration: All of the C++20/C++23 features listed above are either automatically applied based on compiler settings or optional. If you are still using C++17, or if you are using C++20 or C++23 but do not wish to import the thread pool library and/or the C++ Standard Library as a module, no changes are needed. Optional features overhaul: All optional features are now enabled via a bitmask template parameter instead of macros. This works using if constexpr, std::conditional_t, and concepts (in C++20 and later) or SFINAE (in C++17). This change makes the optional features much easier and more intuitive to use, as you no longer need to
Cited by 0Open access
Barak Shoshany · SoftwareX · 2024
We present a modern C++17-compatible thread pool implementation, built from scratch with high-performance scientific computing in mind. The thread pool is implemented as a single lightweight and self-contained class, and does not have any dependencies other than the C++17 standard library, thus allowing a great degree of portability. In particular, our implementation does not utilize any high-level multithreading APIs, and thus gives the programmer precise low-level control over the details of the parallelization, which permits more robust optimizations. The thread pool was extensively tested on both AMD and Intel CPUs with up to 40 cores and 80 threads.
Cited by 3Open access
Shoshany, Barak · Zenodo (CERN European Organization for Nuclear Research) · 2026
v5.1.0 (2026-01-03) New/changed features: Added detach_bulk() and submit_bulk() member functions to submit tasks in bulk. You can pass either a range of iterators or a container. The mutex protecting the task queue is locked only once for the entire bulk submission, which should improve performance when submitting a large number of tasks; if the tasks were submitted using individual calls to detach_task() or submit_task() instead, the mutex would need to be locked and unlocked for each task. detach_blocks()/detach_loop()/detach_sequence() and submit_blocks()/submit_loop()/submit_sequence() now use detach_bulk() and submit_bulk(), respectively, under the hood for increased performance (the API remains the same). They have also been refactored using helper functions and custom function object classes to reduce code duplication. All submit_* member functions now use a C++17/20 polyfill for std::move_only_function when C++23 is not available (or when using libc++, which at the time of this release has not implemented it yet). This allows them to work without using std::shared_ptr, which should increase performance. If the native extensions are enabled, a pool created with the default constructor will now only use the number of threads available to the process, as obtained from BS::get_os_process_affinity(), which can be less than the number of hardware threads. See #161. Since importing the C++ Standard Library using import std is now supported by all 3 major compilers, the library (and test program) will now use import std whenever the macro BS_THREAD_POOL_IMPORT_STD is defined, as long as C++23 is enabled, without performing any additional checks for compiler or standard library support (aside from the workaround for GCC mentioned below). The BS::tp enumeration is now properly defined as an enum class with the appropriate bitwise operators. Removed the polyfills for std::counting_semaphore and std::binary_semaphore from BS_thread_pool.hpp, as they are not used by the library itself, to reduce the size of the header file. If you need them, you can copy them from the test program BS_thread_pool_test.cpp. On Windows, if the native extensions are enabled, WIN32_LEAN_AND_MEAN is now defined before including <windows.h> to reduce compilation time. Bug fixes: The system macros major and minor (from <sys/sysmacros.h> on Linux) or min and max (from <windows.h> on Windows) are now automatically undefined if they are detected, to prevent compilation errors. This was also done previously, but only under certain conditions; now it is done unconditionally, as some users reported issues. On Windows, NOMINMAX is now defined before including <windows.h>, but the min and max macros are still undefined independently. BS::wait_deadlock is now only exported by the module if exceptions are enabled, preventing a compiler error. See #160. Fixed a typo in BS::thread_pool::submit_sequence() which caused the wrong number of futures to be reserved, potentially resulting in unnecessary reallocations. BS::multi_future<T>::wait_until now correctly waits using the specific clock type passed in the template parameter. Fixed a bug where reset() failed to notify worker threads if the pool was unpaused before resetting. get_os_thread_affinity() and set_os_thread_affinity() now return std::nullopt and false (respectively) on Android, as the API is not supported. See #163. Tests: The test program BS_thread_pool_test.cpp now prints colored output for better readability. This can be disabled by setting the NO_COLOR environment variable. The test program now prints out the Mandelbrot set it generates, downsampled to fit in a terminal window (at 120 character width). This will be in 24-bit color in the terminal, and in monochrome using Unicode blocks in the log file. (If NO_COLOR is set, the terminal output will also be in monochrome.) The test program now looks for default_args.txt in both the current folder and the parent folder when reading default command line arguments. Documentation: Added an example in README.md for getting and setting process affinity. Removed the suggestion in README.md to use the -pthread flag on Linux/macOS, as it does not seem to be necessary in order to use the library, at least on the systems I tested with. If you are using a system that requires it, then you probably already know about it. Updated the instructions in README.md for compiling with GCC using import BS.thread_pool, and added instructions on how to compile the std module with GNU libstdc++. Fixed many typos and inconsistencies in README.md. Known issues: At the time of this release, there is a bug in Clang with libc++ where using std::jthread in a C++20 module causes a compilation error. As a workaround, until the bug is fixed, the thread pool library automatically falls back to std::thread if it detects that Clang and libc++ are being used together with C++20 modules. This workaround can be disabled by defining BS_THREAD_POOL_DISABLE_WORKAROUNDS when compiling the module. At the time of this release, there is a bug when using GCC with libstdc++ on Windows via MSYS2 where the BS.thread_pool module doesn't compile if both native extensions and import std are enabled. As a workaround, until the bug is fixed, the thread pool library automatically falls back to header files if it detects that GCC and libstdc++ are being used together with the C++23 std module on Windows. This workaround can be disabled by defining BS_THREAD_POOL_DISABLE_WORKAROUNDS when compiling the module. Development: The Python script I use for compiling the test program, compile_cpp.py, has received numerous improvements: The script now supports import std with GCC in addition to Clang and MSVC. The script now only recompiles the program if the source file(s), module(s), and optional additional dependencies (added using the flag -n/--deps or the deps field in compile_cpp.yaml) have changed since the binary was created. Use -e/--force to force recompilation. The script now allows disabling exceptions by either defining disable_exceptions: true in compile_cpp.yaml or using the flag -x=true/--disable-exceptions=true (the flag overrides the YAML file). The script can now compile modules independently using the -l/--as-module flag. The script can now clear the output folder using the -b/--clear-output flag (replaces the clear_folder.py script from the previous release). The script can now test compilation using all possible combinations of compilers and C++ standards available in the system using the -y/--try-all flag (replaces the test_all.py script from the previous release). The script now automatically detects the Visual Studio installation path on Windows. The script now implements a more robust mechanism for finding the std module. The script now prints colored output for better readability. This can be disabled by setting the NO_COLOR environment variable. The script no longer disables optimizations when compiling with GCC and modules (since that bug is fixed in recent versions of GCC). Added a VS Code task to compile the test program (or the active file) with all available compilers and all relevant C++ standards, but without running it, to quickly check for compiler compatibility issues.
Cited by 2Open access