Re: Can extra processing threads help in this case?


"Jerry Coffin" <jerryvcoffin@xxxxxxxxx> wrote in message
news:MPG.262bf58bf8ba735989863@xxxxxxxxxxxxxxxxxx
In article
<LuidnT3tuaC7p1_WnZ2dnUVZ_gCdnZ2d@xxxxxxxxxxxx>,
NoSpam@xxxxxxxxxxxxxx says...

[ ... ]

Alternative (a) There are four processes with four queues
one for each process. These processes only care about
executing the jobs from their own queue. They don't care
about the jobs in any other queue. The high priority
process
is given a relative process priority that equates to 80%
of
the CPU time of these four processes. The remaining three
processes get about 7% each. This might degrade the
performance of the high priority jobs more than the next
alternative.

There is no such thing with any OS of which I'm aware. At
least with
a typical OS, the highest priority task is the *only* one
that will
run at any given time. Windows (for one example) does
attempt to
prevent starvation of lower priority threads by waking one
lower
priority thread every four seconds.

The alternative that you show quoted above is called time
slicing and has been available for many decades.

Though the specific details differ, Linux works reasonably
similarly.

Neither, however, provides any set of priorities that will
give
anything similar to what you've described. It just doesn't
exist.

Here is is:
http://en.wikipedia.org/wiki/Nice_(Unix)
I will have to run my own tests to see how the process
priority number map to the relative process priorities that
I provided above. Ultimately the schedule algorithm boils
down to essentially the frequency and duration of a time
slice. There is no need to map to the exact percentage
numbers that I provided.


Alternative (b) each of the low priority jobs checks to
see
if a high priority job is in the queue or is notified by
a
signal that a high priority job is waiting. If a high
priority job is waiting then each of these low priority
jobs
immediately sleeps for a fixed duration. As soon as they
wake up these jobs check to see if they should go back to
sleep or wake up.

This requires that each of those tasks is aware of its own
process
scheduling AND of the scheduling of other processes of
higher
priority. Worse, without a lot of care, it's subject to
race
conditions -- e.g. if a high priority task shows up, for
this scheme
to work, it has to stay in the queue long enough for every
other task
to check the queue and realize that it needs to sleep,
*before* you
start the high priority task -- otherwise, the task that's
supposed
to have lower priority will never see that it's in the
queue, and
will continue to run.

My scheduler will signal all of the low priority jobs that
they need to sleep now. When the high priority queue is
empty, and all of the high priority jobs are completed the
low priority jobs get a signal to wake up now.

Bottom line: you're ignoring virtually everything the
world has
learned about process scheduling over the last 50 year or
so. You're
trying to start over from the beginning on a task that
happens to be
quite difficult.

I see no other way to provide absolute priority to the high
priority jobs (paying customers) over the low priority jobs
(free users). Also I see no way that this would not work
well. If I get enough high priority jobs that the lower
priority jobs never ever get a chance to run that would be
fantastic. The whole purpose of the free jobs is to get more
paying jobs.

If you see something specifically wrong with this approach
please point out the specific dysfunctional aspect. I see no
possible dysfunctional aspects with this design.

This has the same problem outlined above. It adds the
requirement for
a shared memory location, and adding polling code to the
OCR tasks.
See above about ignoring what the world has learned about
process
scheduling over the last 5 decades or so.

I already changed this to signals, they don't waste as much
time.

No -- they're substantially worse. At least all that did
was
occasionally start a lower-priority task out of order.

I see no possible sequence of events where this would ever
occur, if you do please point it out detail by detail.

I already figured out a way around that. Everyone must
have
their own user account that must be created by a live
human.
All users are always authenticated against this user
account. I don't see any loopholes in this on single form
of
protection.

Not even close, and you clearly don't understand the
problem at all
yet. The problem is that to authenticate the user you've
*already*
created a thread for his connection. The fact that you
eventually
decide not to do the OCR for him doesn't change the fact
that you've
already spawned a thread. If he makes a zillion attempts
at
connecting, even if you eventually reject them all, he's
still gotten
you to create a zillion threads to carry out the attempted
authentication for each, and then reject it.

Block IP long before that.


Of course, that also ignores the fact that doing
authentication well
is non-trivial itself.

--
Later,
Jerry.


.

Relevant Pages