Re: [clisp-list] thread priority ?

[<don...@is...>]

 > In that scenario, I believe you're better off with dynamic queue
 > control at the application level rather than thread priorities. If
 > you're overloaded, try to work on less things at the same time
 > rather than a little bit of all of them.

Please tell me what you mean by dynamic queue control.
You mean like not starting a process until you have time for it?
But once you start it you might find that you want it to take less
resources.  Wouldn't changing the thread priority be dynamic queue
control?  That's what I want to do.  I guess I could stop a thread
by interrupting it, but that seems just a very poor approximation
to lowering its priority.  

 > In large (non realtime, non embedded) systems nowadays, priorities
 > are just hints to the OS. It'll nevertheless run all those threads,
 > from time to time. It's quite long ago that I've seen a system
 > where a higher priority indeed prevent low-priority threads from
 > running (for lots of good reasons, e.g. to avoid starving on a lock
 > hold by a low-priority dude). Your typical UNIX will still run the
 > low-priority tasks, just a little bit less often.  And the low
 > priority thread will not even get a smaller quantum once it runs!

This all makes sense and it seems good to me.  Except the "little bit"
less often I hope means substantially less.
Again, I'd like to know what the actual mechanism does on different
platforms in order to make best use of it.

 > For instance, low-priority threads will typically throttle your
 > spinning disk, because of additional head movement. Your total
 > throughput decreases. To avoid that, you really need very clever
 > schedulers that estimate workload *and* I/O load -- per thread!

I agree there are lots of complications.  
I suspect a good place to use priorities would be in granting locks.
But all that does not make thread priorities useless.
For instance, knowing that a high priority process is waiting for a
lock held by a low priority process could increase the priority of
the second, until it releases the lock.

 > Linux had long had ionice (next to the nice command) with the
 > "background" priority, yet IIRC, "background" still has a cost to
 > the HD. You often enough don't get HD seeks for free while a higher
 > priority thread is busy computing stuff, not yet begging for more.
 > That other thread generally claims HD resources too fast, it is I/O
 > bound.
 > 
 > So if you know there's something you can delay, just do that,
 > without causing more pressure on the OS.

What if you find out after it's already running that something else
is more important/urgent ?  Many processes CAN always be delayed
but we want to run them on a reasonable schedule if there's no good
reason not to.
And when you talk about pressure on the OS, there's also the opposite
of pressure - unused capacity.  Why waste it?
If the process is going to mostly be waiting for answers to arrive 
over the network (as many of mine will, I think), there's little cost
in letting it run.