gnrc_ipv6_nib: use recursive mutex instead of mutex for locking#12425
gnrc_ipv6_nib: use recursive mutex instead of mutex for locking#12425miri64 merged 4 commits intoRIOT-OS:masterfrom
Conversation
|
The first thee commits might as well be one. As I'm not sure if this is the case (thread blocks on |
That is the problem in #12408.
No, that is not the point of that mutex. It is just for access protection (since the NIB can also be accessed e.g. by the shell or the application). |
Nah, this makes the change more comprehensible. |
benpicco
left a comment
There was a problem hiding this comment.
The mutex is only used for mutual exclusion and not for signalling, so replacing it with a recursive variant is safe.
|
Restarting Murdock, as the last build was quite old. |
Contribution description
This should make the problem that popped up in #12408 easier to solve. There, since the source address detection accesses the NIB's prefix list interface now to determine the prefix lengths of given addresses. This deadlocks its internal process, however, since this function is also called by the neighbor solicitation send function from within the NIB. With a recursive mutex this can't happen.
I also made the mutex itself private and implemented two functions two lock/unlock it from the outside, which scraped of some 100 bytes of ROM on Cortex M0+.
Testing procedure
and
still pass, pinging between two
gnrc_networkinginstances works.Issues/PRs references
Preparation for a rework of #12408.