cpp: thread: support for std::thread, std::mutex, std::condition_variable, etc

[cfriedt]

This commit adds support for std::thread and std::this_thread when the configured C++ standard is >= C++11.

Fixes #25569

Accompanying sdk-ng PR: zephyrproject-rtos/sdk-ng#735

SeaBIOS (version rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org)
Booting from ROM..*** Booting Zephyr OS build zephyr-v3.0.0-1074-g90c018160af3  ***
version 201703
Running test suite std_thread_tests
===================================================================
START - test_this_thread_get_id
 PASS - test_this_thread_get_id in 0.2 seconds
===================================================================
START - test_this_thread_yield
 PASS - test_this_thread_yield in 0.1 seconds
===================================================================
START - test_this_thread_sleep_until
 PASS - test_this_thread_sleep_until in 0.1 seconds
===================================================================
START - test_this_thread_sleep_for
 PASS - test_this_thread_sleep_for in 0.1 seconds
===================================================================
START - test_thread_get_id
 PASS - test_thread_get_id in 0.1 seconds
===================================================================
START - test_thread_native_handle
 SKIP - test_thread_native_handle in 0.1 seconds
===================================================================
START - test_thread_hardware_concurrency
 PASS - test_thread_hardware_concurrency in 0.1 seconds
===================================================================
START - test_thread_join
 SKIP - test_thread_join in 0.1 seconds
===================================================================
START - test_thread_detach
 SKIP - test_thread_detach in 0.1 seconds
===================================================================
START - test_thread_swap
 SKIP - test_thread_swap in 0.1 seconds
===================================================================
Test suite std_thread_tests succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

Notes:

• Tests pass for CONFIG_ARCH_POSIX=y and CONFIG_ARCH_POSIX=n
• Currently skipping a few tests when CONFIG_ARCH_POSIX=n as we cannot yet auto-allocate thread stacks
• Requires a couple of toolchain header modifications (described in comments / PR)
• Eventually would be ideal to bypass POSIX threads and use Zephyr native threads, but they are a convenient stepping stone

[cfriedt]

The toolchain header include/bits/gthr.h was modified as follows:

#if _GLIBCXX___ANDROID__
#include <bits/gthr-posix.h>
#elif defined(__ZEPHYR__)
#include <bits/gthr-zephyr.h>
#else
#include <bits/gthr-default.h>
#endif

The file include/bits/gthr-zephyr.h is a copy of the upstream gthr-posix.h with the following additions. Normally, I would suggest keeping this in the toolchain, as this file is GPLv3. It is included here for reference purposes only.

#define __GTHREADS 1
#define __GTHREADS_CXX0X 1
#define _GTHREAD_USE_MUTEX_TIMEDLOCK 1
#define _GLIBCXX_USE_NANOSLEEP 1

struct __sFILE_fake {
	unsigned char *_p; /* current position in (some) buffer */
	int _r; /* read space left for getc() */
	int _w; /* write space left for putc() */
	short _flags; /* flags, below; this FILE is free if 0 */
	short _file; /* fileno, if Unix descriptor, else -1 */
	struct __sbuf _bf; /* the buffer (at least 1 byte, if !NULL) */
	int _lbfsize; /* 0 or -_bf._size, for inline putc */

	struct _reent *_data;
};

typedef long _off_t;
typedef unsigned long size_t;
typedef long ssize_t;
#define _fpos_t long
#define __FILE struct __sFILE_fake
typedef __builtin_va_list __gnuc_va_list;
#define PTHREAD_MUTEX_INITIALIZER {0}
#define PTHREAD_COND_INITIALIZER {0}

#include <posix/pthread.h>

#if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \
     || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK))
# include <posix/unistd.h>

[ortogonal]

@cfriedt is there any reason why this pull-req is not progressing forward?

I'm also very interested in getting better C++ support into Zephyr and would like to help out. Is there any specific I can help out with here?

I've tested this PR with the SDK changes mentioned above and my 5-min test says it works fine.

[cfriedt]

@cfriedt is there any reason why this pull-req is not progressing forward?

@ortogonal
The biggest reasons are

1. Zephyr has no way currently to dynamically allocate a thread stack (there is a draft pr for that kernel: support dynamic thread stack allocation #44379)
2. The related toolchain integrations need to happen (some work for @stephanosio)
3. Additional work may be necessary around k_mutex (iirc, there may be some static requirement for Zephyr mutex objects)

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cfriedt]

Hi @AfflatusX -

There is a known issue and fix, documented here

zephyrproject-rtos/sdk-ng#751
zephyrproject-rtos/gcc#31

I'm not sure what release this will be integrated into in the Zephyr SDK.

@stephanosio is the C++ maintainer and SDK maintainer, and might have a better idea.

[AfflatusX]

@cfriedt - Thanks for the quick reply! I can fork/patch your PR in the meantime. However, when I pull the v0.16.6 branch and try to build the toolchain using contrib/linux_build_toochain.sh it failed at the GCC step with following output:

[ALL  ]    Using host-linux.o for host machine hooks.
[ALL  ]    c11 is an unknown thread package
[ERROR]    make[2]: *** [Makefile:4565: configure-gcc] Error 1
[ALL  ]    make[2]: Leaving directory '/home/txie/zephyr-sdk-build/build-arm-zephyr-eabi/.build/arm-zephyr-eabi/build/build-cc-gcc-final'
[ERROR]    make[1]: *** [Makefile:1038: all] Error 2
[ALL  ]    make[1]: Leaving directory '/home/txie/zephyr-sdk-build/build-arm-zephyr-eabi/.build/arm-zephyr-eabi/build/build-cc-gcc-final'

I tried to search for the message c11 is an unknown thread package but couldn't find anything useful. Any thoughts?

[cfriedt]

@cfriedt - Thanks for the quick reply! I can fork/patch your PR in the meantime. However, when I pull the v0.16.6 branch and try to build the toolchain using contrib/linux_build_toochain.sh it failed at the GCC step with following output:

I tried to search for the message c11 is an unknown thread package but couldn't find anything useful. Any thoughts?

I would guess that some changes were reverted in sdk-ng and possibly elsewhere.

[AfflatusX]

@cfriedt - Thanks for the quick reply! I can fork/patch your PR in the meantime. However, when I pull the v0.16.6 branch and try to build the toolchain using contrib/linux_build_toochain.sh it failed at the GCC step with following output:
I tried to search for the message c11 is an unknown thread package but couldn't find anything useful. Any thoughts?

I would guess that some changes were reverted in sdk-ng and possibly elsewhere.

hmm, I'm sitting on the v0.16.6 tag:

txie@HABOR:~/sdk-ng-atomic$ git log
commit 2d488e6bef4bc258c0061f12d33ac083acd9ae1d (HEAD -> threads, tag: v0.16.6)
Author: Stephanos Ioannidis <[email protected]>
Date:   Mon Apr 29 14:59:17 2024 +0900

    VERSION: Bump to 0.16.6

looking at the CI history, this commit passed the full CI suite, so it should build successfully right?

Is there a branch contains your latest patches with thread enabled I can give it a try locally?

my bad, forgot gcc is a sub module, need to update separately.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cfriedt]

This needs a rebase and re-rev of SDK changes to be made.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.