# Crash using Channels/Conditions with @threads

**URL:** <https://discourse.julialang.org/t/crash-using-channels-conditions-with-threads/15730>\
**Category:** Performance\
**Tags:** parallel\
**Created:** [October 1, 2018, 12:03pm UTC](https://discourse.julialang.org/t/crash-using-channels-conditions-with-threads/15730 "2018-10-01T12:03:55Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![orenbenkiki](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/orenbenkiki/32/5578_2.png) [@orenbenkiki](https://discourse.julialang.org/u/orenbenkiki)\
**Post date:** [October 1, 2018, 12:03pm UTC](https://discourse.julialang.org/t/crash-using-channels-conditions-with-threads/15730/1 "2018-10-01T12:03:55Z")

</div>

Following up on [Recommended way to do work stealing in Julia](https://discourse.julialang.org/t/recommended-way-to-do-work-stealing-in-julia-1-0/15573), I have tried writing a small scheduler myself and uploaded it to [Github](https://github.com/orenbenkiki/snarl).

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](https://github.com/JuliaLang/julia/pull/22631) 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 ☹

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [October 1, 2018, 10:08pm UTC](https://discourse.julialang.org/t/crash-using-channels-conditions-with-threads/15730/2 "2018-10-01T22:08:48Z")

</div>

The partr PR (the one you linked) is the one which implements/utilizes libuv in a thread-safe manner. Libuv provides the basis for `Channel`s and `Condition`s, 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.

---

<div class="post-metadata">

**Author:** ![orenbenkiki](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/orenbenkiki/32/5578_2.png) [@orenbenkiki](https://discourse.julialang.org/u/orenbenkiki)\
**Post date:** [October 2, 2018, 6:43am UTC](https://discourse.julialang.org/t/crash-using-channels-conditions-with-threads/15730/3 "2018-10-02T06:43:28Z")

</div>

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!