Sebastian Huber created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1481
Project:Branches: sebhub/rtems:up/thread-timeout to rtems/rtos/rtems:main Author: Sebastian Huber ## Summary Issue #5756: score: A time of day set dispatches inside the watchdog tickle Issue #5733: A timeout ends a wait which already ended Thirteen commits, each one a step towards the three fixes. The first disables the thread dispatch around the realtime tickle of `_TOD_Set()`. `_Watchdog_Do_tickle()` calls a service routine outside the lock of the collection and with interrupts enabled. `_TOD_Set()` runs in the task which calls `rtems_clock_set()` or `clock_settime()` and held no dispatch. A thread dispatch point in a routine took the processor away in the middle of the tickle. An interrupt which readies a task of a higher priority did the same, because the level returns to zero when the interrupt ends. A timer service routine which `rtems_clock_set()` calls may no longer call a directive which blocks. That is already the rule for a service routine of the clock tick. The second adds the validation test of that requirement. It arms a task based timer and sets the clock beyond the time point of it. The routine reports whether the thread dispatch is enabled. The third lets the wait class alone name a started wait and drops `THREAD_WAIT_STATE_INTEND_TO_BLOCK`. It adds `_Thread_Wait_flags_exchange_release()`, so a party which ends a wait writes the ready value once rather than running a compare and exchange loop. The same dance stood in five places. The fourth gives `rtems_task_wake_after()` and `rtems_task_wake_when()` the new `THREAD_WAIT_CLASS_TIME`, so the flags of a sleeping thread say that it sleeps. The fifth moves the state to bit 0 and the class to bits 1 to 5, which frees bits 6 to 31, and renames `THREAD_WAIT_CLASS_OBJECT` to `THREAD_WAIT_CLASS_QUEUE`. The sixth gives the flags a generation in bits 6 to 31. The generation steps at the end of every wait, so the value names one wait of the thread. The seventh lets a watchdog carry an opaque token which the party who schedules it writes. `_Watchdog_Do_tickle()` reads the token under the lock of the header and hands it to the service routine, so the token belongs to the schedule which expired. The token sits between the routine and the expiration time point, so the structure grows by no word on a 32 bit or a 64 bit target. The eighth writes the thread wait flags of the wait into the token when the wait arms the timer. `_Thread_Timeout()` compares the token against the flags of the thread and does nothing where they differ. A tickle phase runs with thread dispatch disabled, so only another processor can start the new wait. The comparison is therefore built in an SMP configuration only. The ninth adds the validation test of that requirement. The runner arms the timeout of a worker and moves the worker to the second processor. The link wraps `_Thread_Timeout()`. The wrapper ends the first wait of the worker and waits for the second wait before it calls the real routine. The tenth adds the field `timer_generation` to the period, which names one schedule of the timer. `_Rate_monotonic_Insert_timer()` steps it and writes it into the watchdog token, and `_Rate_monotonic_Remove_timer()` steps it, so the token of a schedule which ends names no schedule. `_Rate_monotonic_Timeout()` compares it against the field under the lock of the period and returns on a mismatch. The field sits in the padding which the `uint64_t latest_deadline` already leaves after `postponed_jobs`, so the period does not grow. This comparison is built in an SMP configuration only for the same reason. The eleventh adds the validation test of the two requirements which the tenth meets. The owner arms the period on the first processor and then runs on the second one. The link wraps `_Rate_monotonic_Timeout()`, and the wrapper lets the owner act before it calls the real routine. One action lets the owner cancel the period and checks the state of it. The other action lets the owner begin a new interval and checks the wait for it. The twelfth disables the thread dispatch around the tick. `rtems_clock_tick()` expires the watchdogs of the processor of the caller and held no dispatch disable. A task which called it lost the processor in the middle of a tickle phase. sp37 checks the dispatch level in its timer service routine and takes the level which the tick holds. The thirteenth asserts that thread dispatch is disabled at the entry of `_Watchdog_Do_tickle()`. An interrupt handler meets the assertion, because the interrupt entry raises the level. The tickle of spwatchdog takes the dispatch disable which the caller of a real collection holds. The branch shares `coretodset.c` with section 56, so whichever of the two goes second needs a rebase. The trees stay unchanged in the commits which are preparation. Each new test fails before its fix and passes after it. The test suite of `sparc/gr740` runs in the four configurations without a regression. **BSP** `sparc/gr740` in four configurations ยท **Simulator** SIS ## AI Details <!-- Make sure you have read our statement at https://www.rtems.org/generative-ai/ --> ### Prompt used None as a single prompt. The work was done in an interactive Claude Code session on the RTEMS tree. The task was to run the test suites of the simulator BSPs, diagnose every failure and fix the cause. Each change was directed and reviewed. ### AI model used Claude Opus 5 (claude-opus-5), through Claude Code. ### How AI was used for the contribution - [ ] Formatting - [ ] Test creation. - [x] Code comments. - [ ] The entire contribution was generated using AI - [ ] AI code completion such as Copilot in VSCode. The diagnosis and the implementation were produced in that session under my direction, and the commit messages were drafted there. ### Access I have not used a product which claims copyright in its output, and I have legitimate access to the one I used. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1481 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-4fqcwsv1zhvlbsqxdi79hxfqw-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
