Re: thread priority ?

Don,

Don Cohen answered:
Vladimir Tzankov writes:
> > I purposely avoided exposing thread priorities. I've yet to see
> > legit use case for playing with these.
>So, for instance, I might assign priority based on how much service a user has already
>received plus the estimated costs of his requests currently in the queue ahead of
>this one (so lower value is "higher" priority).

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.

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!

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!

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.

Regards,
	Jörg

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list