Closed t-yabui closed 1 year ago
Hi @t-yabui I am able to re-create what you are observing. We are working on a fix.
Hi @t-yabui - we have a fix. The code will be pushed to github sometime in the next month. If you would like it immediately, see attached. tx_thread_wait_abort.txt Please let us know if this works for you.
@goldscott
Thank you for the modification. I confirm attached code.
As a result, tx_semaphore_get()
and other APIs(*) returns expected result.
I think this problem has been solved.
(*) I tested tx_event_flags_get()
tx_byte_allocate()
and tx_block_allocate()
.
Fixed in 6.2.1 release.
Describe the bug
tx_thread_wait_abort()
wipes a semaphore in exceptionally rare case.tx_semaphore_get()
API.tx_semaphore_put()
ortx_semaphore_ceiling_put()
API.tx_thread_wait_abort()
API to release Thread A at the time.In consequence :
tx_semaphore_put()
APItx_semaphore_get()
API.In spite of the above, the semaphore is empty in exceptionally rare case. In normal case, the semaphore is added. I expect it.
To Reproduce
The reproduction is very difficult because the timing is severe. However, if you inserts a delay loop in the place of the following codes, it become easy to reproduce.
https://github.com/azure-rtos/threadx/blob/4e62226eeaf870827facbeef40bd1767db5cf9f0/common/src/tx_semaphore_put.c#L203-L206
as below :
When
tx_thread_wait_abort()
API wakes up Thread_A after TX_RESTORE, maytx_semaphore_put()
API not wake up Thread_A with TX_SUCCESS?