xiaoxiang781216 commented on PR #16360:
URL: https://github.com/apache/nuttx/pull/16360#issuecomment-2875132203

   > > @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 your 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).
   
   perfect, thanks for explain the holder meaning so clear.


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to