Suggested improvement for lwsem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Suggested improvement for lwsem

633 Views
chrissolomon
Contributor III

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

Tags (3)
2 Replies

373 Views
RadekS
NXP Employee
NXP Employee

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

0 Kudos

373 Views
chrissolomon
Contributor III

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