> > On 2008-06-25 at 10:18:56 [+0200], André Braga <meianoite@xxxxxxxxx> > wrote: > > I'm not disputing this at all. What I am saying, instead, is that > > sometimes the same thread might behave in a way, and in the next > > moment behave completely differently, and any given priority level > > might not capture this subtlety. > > I believe this actually happens quite rarely. Most of the time > threads have > very specific purposes. E.g. a window thread handles user interaction > and > drawing, a worker thread does, well, heavy work, a media producer/ > consumer > thread will produce/consume media,... > > I don't even think that the need for a low latency can be associated > with > semaphores at all. A thread normally runs through more than one > semaphore. > In case of a video consumer thread displaying the video on screen > this > would involve not only the wait-for-the-next-frame semaphore (which I > understand is your intention to brand with "low latency") but likely > also a > window lock and ports for app server communication, which you can't > reasonably brand, since they are shared with other threads. It seems > obvious to me that low latency is almost purely a thread property and > the > existing (and probably totally sufficient) means for encoding that is > the > thread priority. Indeed, +1. What might be interesting to explore would be priority inheritance, but I'm not sure it's worth it either. François.