core: mutexes memorize holding thread id#4555
core: mutexes memorize holding thread id#4555Kijewski wants to merge 4 commits intoRIOT-OS:masterfrom Kijewski:issue-4494
Conversation
The code is much clearer IMO. atomic_set_to_one() uses disableIRQ() for most platforms, so using to causes an overhead.
There was a problem hiding this comment.
Should I return the information whether the caller had to wait to get hold of the mutex? The API change would not affect any existing code, but I cannot think of a case when you would need this information.
There was a problem hiding this comment.
Same here... It would (slightly) hurt performance in all cases, and can maybe be emulated by calling first mutex_trylock, then mutex_lock.
|
Nice. I would have thought that always disabling IRQs would hurt non-locked case, but it turns out that it's a lot faster this way (330k vs 480k locks/second on sam r21). |
|
But IMHO the PR title is misleading, not using atomics is not a trivial change, and has nothing to do with storing the holder's PID. Not storing the PID (using this PR's code but using 0 and 1 instead of PID) saves another 16 bytes code (on cortex M0). edit @Kijewski Would you mind seperating those changes? |
Hangs somewhere for me. Could you check out #4557? I had a branch lying around which drops mutex' dependency on priority_queue. I've integrated your ideas from this PR. Result is 4% more speed, 20 bytes code saved and |
|
IMO any non-trivial change to the core shouldn't be labeled as "minor". |
|
Closed in favor of #4557. |
Rationale: see #4494. Closes #4494.
examples/default: