qthreads
qthreads copied to clipboard
Lightweight locality-aware user-level threading runtime.
The `qarray` test hangs with thread sanitizer (x86-64, nemesis, clang17, no topology detection). Prior to hanging though, it also emits various thread sanitizer errors: atomic write: https://github.com/sandialabs/qthreads/blob/619afe98edce0098f656c32acf09a12789becad0/src/ds/qarray.c#L738 non-atomic read of...
Running on x86 with clang17, nemesis scheduler, no topology detection, and thread sanitizer enabled, the `qthread_disable_shepherd` test crashes intermittently. Unfortunately this only happens outside the debugger so more work is...
The Readme is very out of date. It references various architectures (e.g. Tilera) that are unlikely to work anymore. This should be fixed.
There are a handful of thread sanitizer errors pointing to various things in our `qt_loop` interface implementation. One of the more interesting ones happens when running the `qt_loop_balance` test: Non-atomic...
The following tests fail during finalization with thread sanitizer enabled (clang 17, nemesis scheduler, no topology detection, x86): `aligned_writeFF_basic`, `reinitialization`, `qthread_stackleft`, and `sinc_workers`. Interestingly, these tests do not fail when...
`QTHREAD_FASTLOCK_LOCK` and the related functions need to be rewritten to use atomic reads and writes instead of relying on the atomicity guarantees from x86. For example, there's currently a race...
There's a race condition and use after free bug in the Nemesis threadqueue termination code where a worker thread may access a queue node after the main thread has already...
Even though the CI workers are small, we should be testing with more threads for the "basics" and "features" sections of the test suite. Given that some of the schedulers...
I'd really prefer if we could make our implementations of various synchronization primitives and data structures rely on C11 atomics and some additional architecture property defines instead of referring to...
Currently by default the `QTHREAD_CASLOCK` macros are a bunch of no-ops. We should just get rid of them. They give the appearance of synchronization in places where it's actually not...