Re: Can extra processing threads help in this case?


"Jerry Coffin" <jerryvcoffin@xxxxxxxxx> wrote in message
news:MPG.262bdaa1b1d36c65989861@xxxxxxxxxxxxxxxxxx
In article
<0KSdnUkKA-hkXVzWnZ2dnUVZ_sWdnZ2d@xxxxxxxxxxxx>,
NoSpam@xxxxxxxxxxxxxx says...

[ ... ]

Since I only need to be able to process 100 transactions
per
second the speed of these overhead sort of things should
not
be too critical. I am guessing that the sum total of
these
overhead sort of things will only take about 10 ms per
transaction most of this being drive head seek time.

As I said before, you really need to build *something*
that works to
at least some degree and start doing some measuring. Right
now, your
guesses seem to lack any basis beyond what result you'd
like to get.

The two most unresolved issues with my design:
(1) The best means to provide one higher level process
with
much higher and possibly absolute priority over three
other
types of jobs.
The two current proposals are:
(a) Assign a much higher process priority to the high
priority jobs. The jobs are executed from four different
FIFO queues.
(b) Have each of three lower priority jobs explicitly put
themselves to sleep as soon as a high priority job
becomes
available. The lower priority jobs could be notified by a
signal.

I don't see where anybody who has a clue has proposed
either of these
-- both of them are fairly poor. The idea of four separate
queues is
pointless and stupid. As both Joe and I have pointed out,
what you
want is a priority queue. With four separate queues, race
conditions
are almost inevitable -- for example, you check the
top-priority
queue for a job first and find it empty, so you check the
second
priority and then the third, and (just for the sake of
argument,
we'll assume you find a job there and start it -- but
didn't notice
that while you were doing the other checking, a job was
inserted into
the top priority queue, so you end up doing a
lower-priority job
ahead of a higher priority one.

One of four different processes only checks its own single
queue.

I think that it only seems stupid because you did not
understand what I am saying. That may be my fault I may not
have explained it well enough.

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.

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.

These processes could even simply poll a shared memory
location that contains the number of high priority jobs
currently in the queue. From what the hardware guys have
told me memory writes and reads can not possibly garble each
other. Because of this, the shared memory location would not
even need to be locked. One writer and three readers.

Neither of these designs has any of the behavior that you
mentioned.


(2) The best way(s) to provide inter process
communication
between a web server that inherently has one thread per
HTTP
connection and up to four OCR processes (with a single
thread each) one for each level of processing priority.

This one is simple: switch to a web server that isn't
completely
broken. Seriously, something that's built around a
thread-per-
connection model simply has no chance whatsoever of
working worth
anything -- ever. Just for one obvious point, this model
makes a DoS
attack really trivial -- somebody can just create several
thousand
connections, and your system will spend its time switching
between
the thousands of connection threads, and (virtually) stop
any real
work from getting done.

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.


--
Later,
Jerry.


.