iam a bit curious about the plans for concurrency in Julia. As far as I understand the documentation, there is no real and easy support for Multithreading atm. The Task API provides an Interface for batch execution on a single OS Thread while Distrubtion starts new processes and setup communication channels. The Multithreading API provides a macro with a parallel for loop which assigns work to threads managed in a static pool but blocks if the pool is busy. I was wondering if there are plans to provide a clean interface like pthreads which allows more freedom in developing concurrent applications. A more generic Future-Promise concept using configurable Executionengines (like in Scala) above the Threading interface together with Tasks would make it possible to develop powerful asynchronous applications like webservers in an elegant way.
Hey @fraxx001, I don’t have much knowledge on the current development of concurrency in Julia. But I’ll share what I do know and hopefully someone can add to this.
About 10 months ago some of the creators of the Julia Language did a reddit ama where Stefan Karpinski gave the following comment on the future of parallelism in Julia:
Julia already has OpenMP-style for loop multithreading, but we’re nearly ready to merge a pull request that implements M:N mapping of tasks onto hardware threads, which will make Julia’s threading system similar to Go’s but tuned for extreme computational performance rather than for writing concurrent servers (although you can do that as well). As we see the number of cores on CPUs go up and the amount of memory per core go down, this will increasingly be a huge competitive advantage over other dynamic languages that don’t have any plausble answer to multithreading.
You can start with the hyperlinked pull request above and look around to see the progress. However, I haven’t seen a more official update on the state of concurrency in Julia.
- Multithreading is a #2 in the “Compiler work priorities”
- You can check the current
multithreadingpulls : https://github.com/JuliaLang/julia/pulls?utf8=✓&q=is%3Apr+label%3Amultithreading+sort%3Aupdated-desc+
- see more: Question regarding Julia's planned approach to composable, safe, and easy multithreading
That PR has been superseded by many other PRs that implement its functionality, and all of those have already been merged. The PARTR functionality therefore already exists in Julia, but there’s no idiomatic way to turn it on; you can do so manually by doing
task.sticky = false and then scheduling
task. This will run that task in the shared PARTR scheduler, in parallel with any other non-sticky tasks, across multiple threads automatically.
Just to add, I believe this macro was shared in Slack as an easy way to try out the functionality:
macro par(expr) thunk = esc(:(()->($expr))) quote local task = Task($thunk) task.sticky = false schedule(task) task end end
Thanks a lot for the answers. I will have a look into the PARTR implementation. The Julia core dev team does a great job by implementing so many features so quickly and stable. But it’s a bit hard to keep track of the current state of work and expected changes without searching through github tickets.
Yes, it’s hard to keep track of things, even for people who participate in development
I’ve been following the threading work with a lot of interest and there’s been many changes merged recently to make the runtime and standard library more thread safe, and to improve performance. There were various changes merged before 1.2 release was branched, but you probably need to be on master if you want to experiment properly with the new work.
At this stage I believe the parallel task runtime generally works but there’s various places which need more synchronization. For a really nice talk describing some of the ideas which are going into making a composable scheduler, see https://www.youtube.com/watch?v=YdiZa0Y3F3c&t=986s
Personally I think the runtime is shaping up to be a really powerful and cutting edge system for composable parallel performance, I’m excited! The next big step is to figure out how to expose all this to the user in a nice way which makes building concurrent applications composable at the API level. I’m not sure anyone is tackling this yet, but there have been some interesting discussions about structured concurrency.