Hi,
we have just spend a few days tracking down a bug in our application, (running on MQX 4.0.1).
The problem ended up being tracked down to lw semaphores being in the linked list after they were freed by task destruction.
Subsequent allocation reused the memory, so the behavior was unpredictable and changed with seemingly unrelated alterations.
I know this can be solved by putting the semaphore struct pointers into a context and having a task exit function, but I this is laborious.
I suggest that in the default task exit handler, prior to freeing memory allocated by the task, the semaphore linked list be checked to see if the any of the semaphore structures are within blocks to be freed.
I realize that this is an overhead, but task destruction is not done frequently.
Thoughts?
Chris
Thank you for your proposal, however this is difficult to apply.
Lightweight semaphores are a simpler, low-overhead implementation of semaphores. Lightweight semaphores don’t contain any information about owner therefore system doesn’t know whether it could be destroyed.
Lightweight semaphores are typically used for synchronization between tasks and unpredictable destroy of lightweight semaphore by task exit handler will probably cause application crash (or loose of functionality) in most of cases. So, I believe that it is designer duty to care about synchronization mechanism when they want destroy a task.
Have a great day,
RadekS
Hi, thanks for the feedback.
I understand that the lwsem structure doesn't have owner information, but surely if the structure is freed during task destruction, the semaphore wont work properly - resulting in crash and unpredictable behavior (that's what we saw).
Thanks
Chris