tree 8b5c396f51d46e6e1ae4a5a3d82587b131162ec6
parent e3520c681386fbb2ba64a65c456a84b7f9ff07f8
author Christopher Friedt <cfriedt@meta.com> 1700720023 -0500
committer Chris Friedt <chrisfriedt@gmail.com> 1701091591 -0500

posix: pthread: implement pthread_getconcurrency()

Zephyr must support all functionality of the XSI_THREADS_EXT
subprofiling option group in order to claim it supports that
subprofiling option group.

The XSI_THREADS_EXT option group is critical to be able to
run POSIX threads with statically allocated thread stacks, which
has been a feature of the implementation since it was initially
added.

The pthread_getconcurrency() and pthread_setconcurrency()
functions are the only remaining, unimplemented functions of
the XSI_THREADS_EXT option group.

Implement pthread_getconcurrency() and pthread_setconcurrency()
via the more "posixly correct" interpretation of the
specification.

I.e. as the pthread_t:k_thread relationship is 1:1 and not M:N,
Zephyr does not support multiplexing of user threads on top of
schedulable kernel entities (i.e. "user threads" are directly
mapped to native threads, just like linuxthreads or NPTL are in
Linux).

For that reason, to be "posixly correct", we should save the
provided value via pthread_setconcurrency(), in the absense of
errors, and also return that same value back via
pthread_getconcurrency(), even though that serves zero purpose
in Zephyr for the foreseeable future.

Note: the specification also states
"an implementation can always ignore any calls to
pthread_setconcurrency() and return a constant for
pthread_getconcurrency()."

For that reason, the implementation may be revisited at a later
time when when considering optimizations and when there is a
better system in place for documenting deviations.

Any such optimization should be explicitly controlled via
Kconfig.

Signed-off-by: Christopher Friedt <cfriedt@meta.com>