Crash using Channels/Conditions with @threads

General Usage Performance
1

Following up on Recommended way to do work stealing in Julia, I have tried writing a small scheduler myself and uploaded it to Github.

The scheduler itself isn’t the point of the project - it is meant to be an internal module, which I would hopefully be able to replace with directly using tasks when PR22631 is merged.

That said, I have had to resort to using a busy-wait implementation to wake up my “idle” threads. Using a Channel or a Condition instead causes a segmentation fault (!).

This should be easily replicated by setting either to_use_channels or to_use_conditions to true inside Configuration.jl. Strangely, if I set to_println_on_debug to false, I get a deadlock in both cases (!).

Having struggled with the code for a while, I don’t see what the bug is. I am fervently hoping the bug is in my code and not some edge case when using a Channel or a Condition to communicate between threads.

If it is such an edge case, I guess I should open a bug report using this code (as it seems very reproducible). The project might not be quite a “minimal code sample”, but it is simple, small and thoroughly documented.

Any advice/feedback will be greatly appreciated!

Edit: Just tested on v1.0.1, same issues.

Edit 2: It seems there’s no current way to have thread-safe wait/notify functionality, other than a busy-wait loop :frowning:

2

The partr PR (the one you linked) is the one which implements/utilizes libuv in a thread-safe manner. Libuv provides the basis for Channels and Conditions, so with its current implementation not being thread-safe, you should definitely expect segfaults. Similarly, if you try to sleep or print from multiple threads (both of which call into libuv), you will also get segfaults, unless you implement locking around these statements very carefully.

3

Ah, that explains things.

It seems that there is no current mechanism to pause/notify a thread, other than to manually busy-wait.

Hopefully the PR will be merged “soon”.

Thanks!