Towards enabling multi-threading on master

[ViralBShah]

I am wondering what it takes to enable multi-threading in the default build on master. Clearly we have loads to do, but while it is still not turned on by default, we won't get the mass testing.

I believe the steps are to enable Travis support first, where everything is tested with multi-threading enabled. Then, turn it on in master, and finally fix all the issues that show up.

Is this possible to pull off in the 0.5 release timeframe? As always, it would be great to try and have a release at JuliaCon.

[eschnett]

See #15647...

[kpamnany]

Fixes needed:

• Threaded build broken on Darwin 15.4 #15647
• Freeze in GC for multithreaded code #15620
• Warning and slowdown for multithreaded Julia code #15740

Additions needed:

• Introduce spawn/sync in addition to the parfor we have now
• Integrate tasks with threads
• Get I/O working in threads
• Handle exceptions in threads properly
• Add more performance tests

I'm actively working on the additions now.

[ViralBShah]

I think at the very least, multi-threading can be turned on in travis with 1 thread right away (except on mac).

[yuyichao]

It can be tested on travis/appveyor with more than one thread (the travis version of osx also doesn't have the clang bug that breaks the build). The only issue is if we want to test non-threading build at the same time and the longer queue as a result of it.

[eschnett]

I don't think there have been cases where threading led to spurious bugs. I don't think it's necessary to have non-threading tests at the same time.

[yuyichao]

Threading and non-threading uses different codegen path and that's the part that is broken the most often if they are not both tested.

[tkelman]

Is the non threading codegen path going to continue to be used indefinitely for some reason?

[yuyichao]

The difference in code path is mainly how we general tls reference which is used for gcstack and current exception. Of course for non-threading build it is not actually tls so we replace it with the global symbol/address directly. This can't be done for the threading build.

If we want to use the threading code path for non-threading build we'll need to pay the cost for a function call (a few cycles) for tls lookup in non-threading build.

[tkelman]

I guess the question is whether it's going to be noticeable. So I think the immediate path forward is to propose enabling the thread flag by default in a PR and run the benchmarks on it.

If it is a noticeable problem, could we maybe trigger the old path via an opt in annotation macro?

[vtjnash]

If it is a noticeable problem, could we maybe trigger the old path via an opt in annotation macro?

to some extent, yes: we could hardcode the TLS value for thread 0 (although, what's the point then of turning on multi-threading). and we would still pay the performance penalty in sysimg code & C code, etc. I don't think I would be in favor of allowing this added complexity into the language semantics.