search

eclipse-threadx / threadx

Eclipse ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications.
https://github.com/eclipse-threadx/rtos-docs/blob/main/rtos-docs/threadx/index.md
MIT License
2.89k stars 784 forks source link

Threadx Linux port: Threads getting stuck when system time is set back until system time catches up #260

Closed akashjjohnWs closed 1 year ago

akashjjohnWs commented 1 year ago

Describe the bug When the system time is set to a value in the past from a thread, all the other threads seems to be stuck. All other threads except the one that sets the time seems to stop running. When the system time catches up, the threads seem to resume. Like if we set the system time back 10 seconds, for 10 seconds all other threads seem to stop running. I am using v6.2.1_rel version of threadx.

To Reproduce Steps to reproduce the behavior:

  1. Clone threadx source.
  2. Configure to build for linux gnu(cmake -Bbuild -G"Unix Makefiles" -DTHREADX_ARCH=linux -DTHREADX_TOOLCHAIN=gnu ./) and build library.
  3. Build a threadx application(A few threads printing something to stdout and one thread to set the time back using settimeofday) linking the library.
  4. Run the binary.

Expected behavior The system time should be set back, but all threads should continue to work ok.

Impact The application is for an embedded system running a linux based OS. The app should be able to set time based on user input. So if the user sets the clock back the applicaion sort of gets stuck. Will have to exit and restart the app each time the time is set which is not desirable.

TiejunMS commented 1 year ago

@akashjjohnWs , just so you know, ThreadX for Windows/Linux are simply a simulation. It is designed to run regression test and easy for application development. The OS scheduler and timer interrupt are not fully controlled by ThreadX. I would not call this as a bug when system time is changed. ThreadX for Windows/Linux should not be used in a product.

akashjjohnWs commented 1 year ago

We found a fix for the issue. Replaced the sem_timedwait call in _tx_linux_timer_interrupt(ports/linux/gnu/src/tx_initialize_low_level.c) with sem_clockwait with CLOCK_MONOTONIC and that solved the problem.

TiejunMS commented 1 year ago

@akashjjohnWs, thanks for sharing the solution! Since sem_clockwait is not POSIX compatible, we will look into it future and put this task into internal backlogs. I'm closing this issue for now. Feel free to reopen if you have further questions.