Re: Subject: [PATCH 2/2] priority System V Semaphores
From: Raz <hidden>
Date: 2011-12-22 13:00:47
Also in:
lkml
On Thu, Dec 22, 2011 at 10:59 AM, Peter Zijlstra [off-list ref] wrote:
On Wed, 2011-12-21 at 22:48 +0200, raz ben yehuda wrote:quoted
Vxworks is the use case. And there are plenty of companies with vxWorks software and in i believe they will migrate sooner or later to PreemptRT. My current company uses old wrapper software that implements vxWorks semaphores as system V semaphores. vxWorks semaphores have a priority feature which is widely used. I will probably change it some time in the future to posix semaphores , but posix semaphores are implemented in glibc with futexes and atomic ops and i rather mess with kernel and not glibc. funny , but true. glibc is harder.Semaphores are a fscking trainwreck for real-time programming. Don't use them, full stop. If you do, you're doing it wrong, it's really that simple. Use PI mutexes, which are already fully supported in glibc, no extra patching needed. Full NAK for any and all priority fudging for any semaphore implementation.
please correct me if am wrong, " posix semaphores are implemented with pi mutex. ..?" I need a counting semaphore. vxWorks priority/fifo semaphores are different from posix semaphores in that the behaviour is defined on the semaphore and not the thread. Q: what happens if I want one posix semahore to be FIFO and another posix semaphore to be PRIO while both are used by the same thread.should i to change policies each time ? -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html