[haiku-development] Re: The new locking primitives and boosting -- I need some guidance here :)

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.

CU, Ingo

Other related posts: