deadlock in _once()

[Stavros Passas]

RTEMS threads getting locked up when using certain c++ functionality.
Issue happens for example when std::future is combined with std::async.

Investigating deeper, seems like this happens if std::async executes before std::future gets scheduled to run. Both of these create a pthread_once instance.

_once() uses a common semaphore for all calls, thus the first function (async.get usually) gets the lock, calls its “init” function (which blocks until the second function has completed. After this, std::future also uses pthread_once to execute, but because the lock is already taken, it also blocks, casing a deadlock.

Attached you can find a test application that reproduces the deadlock.

[Stavros Passas]

Test Application

[Stavros Passas]

Copying the suggestion from Sebastian, (from the mailing list) about this issue:

"Please open a ticket and provide a test case for the RTEMS test suite. Maybe we have to use dedicated mutexes for each pthread_once_t object. This is what Linux and FreeBSD do. This would require a Newlib update."

[Stavros Passas]

Proposed fix

[Stavros Passas]

I agree with Sebastian, that using one dedicated mutex for each pthread_once_t instance would be a longer term and elegant solution, but it would also add overhead for each pthread_t instance.

I am adding a different proposed solution, which doesn't require newlib changes (and increasing the pthread_t size):

The _once implementation uses a single mutex. Currently this mutex protects the whole function, while I believe we need to protect reads/writes to the once_state variable only. Concurrent tasks finding the state on RUNNING, could just yield until the state becomes ONCE_STATE_COMPLETE.

[Sebastian Huber]

Please send patches to the mailing list.

The yield loop may fail if thread priorities come into play. It should be replaced with a condition variable. So, for the once implementation we need a mutex and a condition variable (#include <rtems/thread.h>). There is currently no condition variable with API mutex support. We need protection from asynchronous deletion. Maybe use _Thread_Set_life_protection() directly in _Once().

If we want to back port this fix to RTEMS 4.11, then we have to use <sys/lock.h> instead of <rtems/thread.h>.

[Chris Johns]

What is happening with this ticket?

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"e4ad14cc789090290550e3aa9640e4969037e8b7/rtems" e4ad14cc/rtems]:

score: Avoid some deadlocks in _Once()

Recursive usage of the same pthread_once_t results now in a deadlock.
Previously, an error of EINVAL was returned. This usage scenario is
invalid according to the POSIX pthread_once() specification.

Close #3334.

[Sebastian Huber <sebastian.huber@…>]

In [changeset:"3d65f457eacbdebe6b67babc05d005e873148f0a/rtems" 3d65f45/rtems]:

psxtests/psxonce01: Fix typo

Update #3334.