Ian Henriksen

Another example from `arbitrary_blocking_operation` in the sherwood/binders config (with more details and line numbers this time): Thread 2: ``` #0 sched_yield () from libc.so.6 #1 in qthread_steal at qthreads/src/threadqueues/sherwood_threadqueues.c:900 #2...

Just saw a similar hang in the `qthread_readstate` test. Specifically with the nvc/sherwood/hwloc config. It's very likely related. I'll see if I can reproduce that locally.

Managed to reproduce this with work stealing disabled (though it's much more rare in that case), so the bug is very likely in the sherwood implementation of `qt_scheduler_get_thread`. Both threads...

For future reference, here's the version that breaks the loop more easily `for ((i=0; i

Tentatively closing this as fixed. #338 seems to have done the trick, at least for the `arbitrary_blocking_operation` test. I was never able to reproduce any of the other seemingly related...

Looks like the `qthread_readstate` failure is still there. It just showed up in one of the arm/gcc/distrib/no-topology builds. My guess is that it's not actually related to `arbitrary_blocking_operation` failure so...

Just saw this somehow show up again in https://app.circleci.com/pipelines/github/insertinterestingnamehere/qthreads/759/workflows/83b3eed1-f4bf-46e8-86e3-dab1b892cd65/jobs/58881. Seems like an anomaly, but the io subsystem still should be more robust to that. For now just documenting this until...

I'm closing the other tsan-related issues since they'll all need to be re-triaged after this one's fixed. Most of what's still showing up now is buggy behaviour and/or false positives...

For example, hwloc on OSX/M1 and on FreeBSD doesn't work right now. It's probably a simple fix, but I'm also not sure if that's something we want to bother supporting.

Fixed in #283 and #277.