My realtime thread is effectively suspended during that wait, so it can't keep any others from running. It would be crazy for the kernel to fail to schedule any other threads while I'm waiting for one of them to release the lock I need. Thread priorities should apply only to threads that are actually doing stuff. If my realtime-priority I/O completion routine tries to take a lock that might be held by an idle-priority GUI thread, why is that a problem? If I'm waiting on a lock, then by definition I'm not running at realtime priority while I'm doing so. I've done a lot of realtime programming but have never had to confront that particular buzzword. ![]() I guess I fundamentally don't understand priority inversion. ![]() Your GUI thread will be running with a much lower priority than the audio thread, so it could be interrupted by pretty much any other process on the system, and the callback will have to first wait for this other process, and then the GUI thread to finish and release the lock before the audio callback can finish computing the buffer - even though the audio thread may have the highest priority on the system. In order for your audio callback to return the buffer on time it first needs to wait for your GUI thread to release the lock. ![]() Let’s say your GUI thread is holding a shared lock when the audio callback runs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |