Implementation of CONFIG_MAX_PTHREAD_COUNT

[SteveOss]

Describe the bug

CONFIG_MAX_PTHREAD_COUNT appears to have been implemented as the maximum number of POSIX threads that can ever be created, rather than what might be expected i.e the maximum number of active POSIX threads. If the former is intended IMHO this is a "bad idea"
in that it breaks any dynamic creation of threads and should be documented, if the latter then is clearly a bug.

To Reproduce

In a loop call pthread_create on a function that immediately returns i.e. the thread starts then
terminates, after a few iterations the function returns EAGAIN as the maximum thread count
has been exceeded.

Expected behavior

I would expect to be able to create POSIX threads and only get an EAGAIN error if I exceed
a configured maximum of running threads. The POSIX use of EAGAIN implies this i.e. try
again later and you may be able to create a thread.

Impact

Breaks standard TCP handling program, where listener creates a new thread to handle a connection.

Environment (please complete the following information):

Am using the v1.14-branch GA release branch and testing on a frdm-k64f, although looking at the source is not platform specific.

Additional context

In lib/posix/pthread.c take a look at use of pthread_num (as a minimum should be an atomic variable or accessed via a mutex, even for existing semantics).

Fix is straight forward:

• Create a mutex to protect pthread_num and associated stack array (posix_thread_pool)
• Add an array to mark usage of posix_thread_pool (e.g. boolean array)
• On thread creation, iterate usage array to find free pool element and increment pthread_num
• On thread exit decrement pthread_num and mark pool element as free.

Probably about 20 lines of code :)

[wentongwu]

not related to your reported issue, did you enable CONFIG_USERSPACE when using POSIX threads?

[SteveOss]

CONFIG_USERSPACE was not configured.

[wentongwu]

wentongwu@8b6edc1
@SteveOss would you like try this patch? Thanks!

[SteveOss]

@wentongwu Patch looks good. We have a bank holiday here today and Monday, so won't be able
till test till Tuesday. Will let you know how I get on.

[wentongwu]

@SteveOss I test this patch on my side, it works well, how about your test?

[SteveOss]

@wentongwu Have pulled your commit and is working for me. Guess the thread pool index could have been stored in the posix_thread struct to avoid the lookup on thread exit, but is no big deal. Thanks for sorting this, is this going to be back ported to the 1.14 release branch?

[SteveOss]

Is this fix going back onto the 1.14 TLS branch ?