jlaitine commented on PR #16360: URL: https://github.com/apache/nuttx/pull/16360#issuecomment-2875003933
> @jlaitine but is it wrong to skip sem holder updating in the fast path if user enable priority inheritance? This is a good question, and raises from a confusion in the original semaphore code.. It is not being skipped; there are always 2 things you need to do with holders: 1) Whenever you acquire semaphore or mutex, the holder needs to be marked to the sem structure (atomically wrt. other threads when becoming holder) 2) Whenever you semaphore boosts priority of a thread, the holder needs to be marked to the boosted thread's list (tcb->holdsem) for priority restoration later The confusing part (and why this question raises) is that these two are done at the same time in one function: "nxsem_add_holder_tcb". And for counting semaphores *both* are done at the same time at 1) . TCB list addition is not done again for counting semaphores when priority boost happens, because it is already done... For mutexes, the holder *is* set atomically at 1) (it is the PID marked to sem->val.mholder). And 2) *is* done when the priority boost occurs, in slow path. For counting semaphores you always need to go to the slow path already at 1) if priority inheritance is enabled, because counting semaphore holders need to be added to the list (sem->holder), which needs to be locked for addition. So you don't need to go to the slow path when acquiring a mutex (unless it is already held causing blocking and priority boost), simply because the only mutex holder is set atomically at the same time when acquiring it (the holder and the value are basically the same thing, set with atomic cmpxchange). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
