xiaoxiang781216 commented on PR #16194: URL: https://github.com/apache/nuttx/pull/16194#issuecomment-2854788694
> > 2. Remove the code which track multiple holder for counting semaphore since it never work as expect and impact the real time > > "never work as expect" _might_ not be correct. I do agree that in most common use case for a counting semaphore is signalling, and it is hard to find real world use cases where you would want the priority inheritance on counting semaphores. > > Perhaps it could also be used as a resource counter where same thread waits and posts on a counting semaphore. Or a case where you want to allow exactly n number of threads execute the code. > semaphore use as the resource counter also can't work with the holder concept too, since the resource acquire and release still happen in the different threads in most case. > Or, for some reason you want to use a counting semaphore as a mutex... > In this case, the semaphore should be a binary semaphore. Even you need the recessive mutex, you still need binary semaphore, not counting semaphore. > I'd like to see proof that it is really useless before doing anything as drastic as removing it completely, even if it would simplify many things. > > Perhaps a better discussion point is, whether the priority inheritance should be enabled by default on counting semaphores or not? To make the holder tracking work as expect, the key requirement is that sem_wait and sem_post is called in the same thread. using semaphore as event notification or resource counting can't match this requirement. Also, I never hear any spec which define the priority inheritance for counting semaphore. -- 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
