Yes and No. For counting semaphores we have multiple holders for example with priorities 10, 50 and 90. Now a task with priority 100 comes and wants to take a semaphore. Priority which of the holders should be increased? The lowest or the highest holder? With a real-time point of view it should be 90 boosted to 100, but is the current implementation doing that?
Let's see how the other RTOS-s are doing that. I do not think that we are the first who meet this design question. Best regards, Petro пт, 31 бер. 2023 р. о 16:04 Gregory Nutt <spudan...@gmail.com> пише: > > > Migration to nxmutex is quite a big effort and unfortunately recently I > > didn't have much time to deep dive into this. In general I support an > > initiative and do not see a use case for priority inheritance for regular > > semaphores, so I think we should clean-up priority inheritance code for > the > > regular signalling semaphores and introduce a new kernel object (mutex) > > instead. This is surely valid for the kernel, but not for the user space > > that already has pthread_mutex with priority inheritance option, so I do > > not see anything is needed for user space. > > Not all locking is binary. The are cases in the OS where there a > multiple instances of a resource that are protected with a counting > semaphore. If there are N things available, N attempts will return a > thing, but the N+1th attempt blocks. If the requester of the N+1th > thing is high priority then priority inversion can occur. > > This is a large change and can affect many people. This appears to be > controversial. Controversial change require a vote of the PMC to > continue. Different rules for "Votes on Code Modification" appear > here: https://www.apache.org/foundation/voting.html >
