[haiku-development] Re: The new locking primitives and boosting -- I need some guidance here :)
- From: "André Braga" <meianoite@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 26 Jun 2008 01:42:27 -0300
On Wed, Jun 25, 2008 at 20:13, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> Yep, 0.5 MB should be right. That doesn't sound a lot, but then again, it's
> physical memory that is lost to the system.
According to François we won't be losing a thing :) And this is the
same 0.5MB that would be "wasted" to implement priority inheritance.
> I'm pretty ignorant with respect to scheduler implementations, but the first
> option sounds exactly like what the scheduler should do.
A scheduler should *not* do this. This is a clever trick to make up
for the absolute lack of knowledge UNIX schedulers have about
interactive processes. Be itself didn't implement this strategy
because it was not necessary on BeOS, which related priorities to
processing roles in a well-defined manner.
> If a similar behavior can be achieved by other, easier means, fine by me.
> Alas I don't think semaphore branding does that. For one, if I understand it
> correctly, a thread that used 99% of its quantum before starting to wait on
> a low-latency branded semaphore will be boosted in just the same way a
> thread that used only 1% would.
True. Meaning that both get boosted when it's critical for them to
receive a boost. As I see it it's not a bad thing at all. And the
fairness of the scheduler algorithm will make sure that both threads
will get their chance to run. If the 1% one is supposed to run more
often, it should have been assigned a higher priority. If both have
the same priority, both should have the same opportunity to run.
Otherwise you see the weird responsiveness effects that René just
complained about regarding Linux.
> Furthermore I'm afraid you just can't brand most of the
> locking primitives a thread runs through, since most of them are shared by
> different threads with different purposes (and thus different priorities).
Branding is absolutely *not* different from priority inheritance in
principle. Branding is to the subsystem as priority inheritance is to
the blocked thread of highest priority. And one doesn't exclude the
other. So if we're finding difficulties in implementing the branding,
we'll face the same difficulties in implementing priority inheritance.
It's the *exact same mechanism*, only the origin of the boost
(subsystem or blocked thread of highest priority) changes.
(Sorry if it took me so long to explain it in these terms!)
> A change of/addition to an algorithm to improve responsiveness would fit my
> definition of optimization, but feel free to call it by any name you like. :-)
Er... Walter? ;D
> As said before (and as I tried to explain by the example in my previous mail)
> most locking primitives can't be branded.
I still fail to see why. You brand an app_server semaphore with
APP_SERVER, input_server semaphore with INPUT_SERVER and so on. What
boosting values should be assigned to these symbolic constants is
still to be defined. I'm proposing high numbers like 500, 1000 etc, to
emulate the effects of the ridiculously high boost that threads that
consume small quanta receive on other OSs.
> And those that you can brand don't really add value. Like the receive
> end of a BWindow port -- it is only used by the window thread, which
> per default has display priority.
Now THAT'S something that I was afraid of: that we have locking
primitives that belong to interactive code paths are part of the
clients, not the servers.
Well, so now what? Branding only works for locking primitives that are
accessed by multiple clients, but so does priority inheritance. When
dealing with message passing, the way a BWindow blocks when trying to
read its own empty queue/semaphore, what are we supposed to do? Make
the message carry a boosting value inherited from the sender, i.e.,
app_server?
Yeesh.
A.
Other related posts:
