Open matheo-lucak opened 8 months ago
Hi @matheo-lucak, Thank you for reporting this. We will take a look at it and come back to you.
Hello @ESP-Marius, we would be interested by this feature too as it is a blocker for our project where we expect periodic clock synchronization with SNTP and use the pthread and mutex functionalities.
Was this issue already prioritized? we consider it as well quite critical.
HI @MaximeVinzio, @matheo-lucak!
The C++ standard library used in ESP-IDF is the upstream library from GCC (libstdc++). As you already pointed out, it will call pthread_cond_timedwait()
and pthread_mutex_timedlock()
under the hood.
To std::chrono:steady_clock
within the timed waiting functions, the GNU C++ standard library requires a set of non-standard functions (i.e., they are not in the POSIX standard). Note that they are only available on fairly recent versions of glibc
, not in newlib
, which ESP-IDF is using, neither on many other operating systems. However, the usefulness of having MONOTONIC clock available for synchronization primitives is acknowledged. Since we are already planning a refactoring of our POSIX portability layer, we might think of adding this feature in the future, but we are not certain yet. We'll keep you updated.
We've discussed this in our team and concluded that adding the API from Glibc is useful. Even though the current restriction to CLOCK_REALTIME
is according to the POSIX standard, we plan to add this in the medium-term future.
Is your feature request related to a problem?
The pthread implementation of condition variables and mutexes uses only
std::chrono::system_clock
which is non monotonic.CPP reference recommends the use of
std::chrono::steady_clock
instead here :Same thing for mutexes here
Having condition variables based on a non monotonic clock will affect waiting conditions if the clock comes to be updated.
We can find the use of the system clock for condition variable here
and here
And for timed mutexes here
And also here
I'm not an security expert, but knowing that condition variable and mutexes are based on system clock, and system clock is often affected by NTP updates on many devices. DNS hijacking and Man-In-The-Middle attacks on NTP could be a very easy attack vector.
Describe the solution you'd like.
Pthread should be configurable to use either the
std::chrono::system_clock
or the monotonicstd::chrono::steady_clock
using the menuconfig tool.Describe alternatives you've considered.
No response
Additional context.
I'm using :