Sure, just combine with a semaphore. You put a message in the queue and then post() on the semaphore (in this order) and then in the worker you wait() on the semaphore and then read from the queue (in this order).Is your RTQueue suitable for this?
edit: In theory a classic producer-consumer queue directly built out of (two) semaphores might be kinda better here, because then you could also handle the "queue is full" situation by waiting for more room in the queue and wouldn't need to separately use the semaphores as such... but like.. idk if it matters.
I'm not sure I follow. The way a semaphore wait() operation and a regular sleep work in any sane operating system is basically the same: the thread is put into a suspended "sleeping" state until an event occurs. In the case of a semaphore wait() that event is someone posting on the semaphore. In the case of a sleep, that event is the timer expiring. Finally if you have a semaphore wait() with a timeout, then it's basically the same as a regular sleep except you also get woken up if the semaphore is posted.I believe that when there is a "wait()", in some way there should be a sleep implementation somewhere (else it will run exclusively).
This also holds for waiting on most other synchronization primitives. Basically the only type of synchronization primitive that doesn't put a waiting thread to sleep is known as a "spin lock" which is essentially a mutex, except unlike a regular mutex the waiting thread just keep busy-looping (spinning) on the lock until it's unlocked. There is usually no good reason whatsoever to use "spin locks" in regular user-space code (usually you only use them in kernel or embedded code where you can't really do a regular sleep for one reason or another)... and many modern mutexes spin a limited number of times anyway before sleeping the thread, which sort of gives you the "best of both worlds" solution.
Statistics: Posted by mystran — Mon Jul 15, 2024 5:46 pm