Re: Can extra processing threads help in this case?

See below....
On Tue, 13 Apr 2010 00:08:10 -0500, "Peter Olcott" <NoSpam@xxxxxxxxxxxxxx> wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in
message news:v7n7s5ttghv8t38aj1oc0o9h6acnvglidi@xxxxxxxxxx
See below...
On Mon, 12 Apr 2010 18:43:38 -0500, "Peter Olcott"
<NoSpam@xxxxxxxxxxxxxx> wrote:

The scheduler pulls off the priority sorted jobs in
priority
order. Since there are no high priority Jobs the scheduler
begins a 3.5 minute low priority job. Immediately
following
this a high priority job arrives. After the 3.5 minute job
completes, the scheduler begins the high priority job that
has now exceeded its real-time threshold by a factor of
35-fold.
****
That's why I gave you the priority-inversion-prevention
algorithm, which is if you have N
handlers you never dispatch more than K < N large jobs,
which means that you have (N-K)
threads to handle the fast-turnaround jobs. But I guess
you missed that part.

And no thread priority fiddling is required to make this
work correctly!

Then how is it that the high priority jobs would always get
at least most of the CPU?
***
They will. And this can shut down your Web server, other critical services of the OS, and
you think this doesn't matter?
****

Pretty straightforward, easy to implement, easy to tune;
you decide what value K needs to
be to meet normal requirements. Simple, straightorward,
easy to implement. What's wrong
with it?

The fact that I still can't see any improvement than my less
complex strategy, and it still seems that my less complex
strategy would have superior performance.
****
Actually, if you think having complex interprocess signaling mechanisms is "simpler", you
have defined "simpler" in a way we have been previously unaware. And you have no evidence
this actually has "superior performance", in fact, you have no evidence about performance
AT ALL.
****

I can neither prove nor disprove dogma, (there just isn't
enough to work with) I can only work with reasoning.
****
Sadly, if I went back to my books on queueing theory, and
found the appropriate formulae,
I seriously doubt you could comprehend them. I suggest
that if you think your approach is
superior, you are guilty of presenting dogma, and you have
not proven it, nor have you
presented any sound reasoning to prove that it works
better than SQMS.

Yes and if you don't still remember the details of this
there is no way to explain these details. Could you maybe
try to find me a good link, I don't know enough about this
stuff to know a good link from a bad one.
****
I don't need to remember the details; I only have to remember the results. Sometimes you
need to do massive amounts of computation to derive a single bit, but once that bit is
derived, you can immediately map a set of input conditions to that bit without having to
work through the entire derivation. It is in this way, we derive patterns we know work,
and reject patterns we know don't work. Go get a book on queueing theory and study it. I
did, many years ago, and I have a set of known-good patterns and known-bad patterns, and
all I need to know are the patterns.
****


Something about pots and kettles comes to mind here,
something about color....

You are guilty of the same issues you are accusing me of.
You are using false assumptions
and perhaps the I Ching to "prove" MQMS is necessarily
better than SQMS, and your only
evidence seems to be "I'm a superb designer". I, at
least, have experience in queueing
theory and realtime embedded systems.
****

I have seen no evidence showing that SQMS is better that how
I implemented MQMS. Perhaps there are certain design
principles and heuristics that tend to show this. I am
totally unaware of these. Whenever I use any design
heuristics or principles I endeavor to always find the
reasoning behind them, that way I never apply them in the
cases where they do not apply. When I do find this
reasoning, I tend to discard the heuristic and principle in
favor of this reasoning.
****
But you have been unable to show what MQMS performance is, given a particular mix of jobs.
I actually showed how to do the arithmetic, step-by-step, and showed that MQMS is going to
be slower than SQMS in a multijob scenario, and just plugged a few numbers into a
closed-form equation to get the results. You can do this, too. And you need to prove
your solution is better, since I already proved SQMS is better.
****

If they work better then there is a reason why they work
better if there is not a reason why they work better then
they don't work better. Please provide the reasoning. As
soon as I see sound reasoning that refutes my view, I
change
my view.
****
You have already pointed out that you have not read my
careful analysis, so why should I
reproduce it here? I wrote it once already.
joe

I never saw it and there was a whole day that I ignored half
of your messages because I was so annoyed with you. Now that
I think that I may have inferred the root cause of this
annoyance, there is no reason for this annoyance to continue
to exist.
****
That is not my problem. That is your problem. Go back and read them. I am not
responsible for your failure to read replies.
****

Could you find this message and tell me the time and date? I
will read it.
****
No, I leave this as an Exercise For The Reader.
joe
****


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.