thread support compiled in the C++ runtime

[kas1e]

For building latest verions of Webkit engine (used in Odyssey browser), we need to have the thread support compiled in the C++ runtime.

For thread support in C++11 on AROS, dedwood use pthread library created by BSzili. OS4 have our own pthreads.library too, but if there can be any problems with, we can use opensource BSzili's pthreads: https://github.com/BSzili/aros-stuff/tree/master/pthreads , as they well tested on morphos/aros.

Here is AROS diff patch which used to build GCC with enalbed chrono, pthreads (with fixes where is need it), so probably that will help a lot to make it all faster:
https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/tools/crosstools/gcc-4.8.3-aros.diff

[kas1e]

Simple test case for tests looks like this:

#include <iostream>
#include <thread>

//This function will be called from a thread

void call_from_thread() {
    std::cout << "Hello, World" << std::endl;
}

int main() {
    //Launch a thread
    std::thread t1(call_from_thread);

    //Join the thread with the main thread
    t1.join();

    return 0;
}                   ^

Compilation of object:

$ ppc-amigaos-g++ -std=c++11 -c thread.c -o thread.o
thread.c: In function 'int main()':
thread.c:12:5: error: 'thread' is not a member of 'std'
     std::thread t1(call_from_thread);
     ^
thread.c:15:5: error: 't1' was not declared in this scope
     t1.join();
     ^

For x86 it compiles well with and without -pthread switch, like:

g++ -std=c++11 -pthread -c thread.c -o thread.o
or
g++ -std=c++11 -c thread.c -o thread.o

For os4 without -pthread switch we have that errors above, with it we have "error: unrecognized command line option '-pthread'"

I checked aros diff from above post, and there seems not many code related to support of pthreads in c++11.

Sebastian, what you think, is it possible to add it to our gcc in the same manner as deadwood do for aros in that diff ?

[kas1e]

Some small addon from deadwood:

The C++11 thread support is there is GCC - there is nothing to implement really. You just need to make GCC correctly detect that you have pthread available or force it to think you have it. If you do, some configuration switches will turn on and you will have the support. I think for AROS, I just forced it to think pthread is available.

[sba1]

If you like, you could try it out by adding the appropriate --enable-threads=posix line to the gcc configure line. Originally, I wanted to write an own thread emulation layer but if posix works it would be much easier for the moment.

[sba1]

The current procedure is to add this flag manually when configuring. You also need a special linker script that changes the constructor calling order such that the libpthread.a one is called for. For this purpose, use a dedicated linker script (e.g., https://github.com/sba1/adtools/blob/master/tests/test-thread-ldscript) until the link lib is fixed.

[Hypexed]

I've come across this pthread issue my self in configure scripts. Usually a failure with discovering posix thread support. But one solution is to change it too -lpthread instead and then it passed. It worked in my case when cross compiling. Don't know about on OS4.

[ksdhans]

Any progress on this issue? Does the latest build allow you to use std::thread out-of-the-box (i.e., no messing with changing scripts, etc.)?

Being able to use std::thread would make both porting and writing code easier (especially if you're working on multi-platform stuff).

[sba1]

Not yet, especially not with shared objects.

[ksdhans]

Not yet, especially not with shared objects.

Pity. Any technical barriers in the way?

Is there any way to get this done quickly? I'd be fine with static linking only, so long as I can use the thread class.

[kas1e]

@sba1
Shared objects can wait for sure, if pure statical linkng will works, its good enough for meanwhile, just set it by default, and all can go from there :)

[sba1]

The problem is that a compiler that is configured with a thread model will generate bad shared objects (bad in a sense that the ABI may change in the future). I'm not sure if there is a solution to switch the thread model at runtime other than to provide two builds.

[ksdhans]

You mean that all shared objects are incompatible with previous versions? Or, that the generated C++ stdlib is incompatible?

Microsoft's Visual C++ has provided multiple C++ libs for years, including ones with and without multithreading ability. I'd be fine with having multiple stdlibs for with and without threading, so long as the correct one is loaded automatically at runtime. Or, I'd use static linking...

Most important is to be able to use key C++11 features in the first place.

[sba1]

I started with the thread support some days ago. The gcc comes with an own abstraction layer that is a subset of the pthreads API. In my implementation, it will be possible to link against different target implementations, so it can be decided at link time, which thread implementation should be used. So far, I implemented the single thread mode (which behaves as before, i.e., no threads are supported) and a native AmigaOS one. The latter one uses AmigaOS interfaces directly and it is not completely finished yet. The object file is called gthr-amigaos-native.o. There will also be a pthread wrapper, for those who require full pthread compatibility.

The patch is developed in the gcc 8 patch queue. You may try it if you like.

[ksdhans]

Great to see progress. I'm pretty busy with other stuff right now, so I'm not sure when I'll get round to trying it out. Hopefully soonish.

[sba1]

It is now possible to choose the actual thread implementation via the -athread option. Possible choices are single, native, and pthread. Still gcc 8 only, but once it is finished, i'll backport it to gcc 6.

Note that native is an own implementation and thus probably contains bugs. And pthread is not provided yet.

[sba1]

The feature is more complete now (but still unfinished in some aspects). But initial work has been done, hence I close this issue. Please file new issues if you find something working weird.