Suggested improvement for lwsem

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Suggested improvement for lwsem

1,673 次查看
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

标记 (3)
2 回复数

1,413 次查看
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 项奖励
回复

1,413 次查看
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