Re: Can extra processing threads help in this case?
Peter Olcott wrote:
http://en.wikipedia.org/wiki/Priority_inversion
If there are no shared resources then there is no priority
inversion.
Try and provide a valid counter-example of priority
inversion without shared resources.
You don't to have a dead lock to reveal problems. You can get Race
Conditions with classic SYNC 101 mistakes like this that depends on
time synchronizations:
if (NumberOfHighPriorityJobsPending !=0)
nanosleep(20);
Since you like wikipedia, read:
http://en.wikipedia.org/wiki/Race_condition
Whats the point of the above? Are you expecting that the value will
turn 0 in the nanosleep(20) which is wrong anyway. Is that 20 seconds
or 20 nanaseconds? Did you really mean?
if (NumberOfHighPriorityJobsPending !=0)
usleep(20);
In either case, you are are in for a RUDE awakening with that.
You probably mean:
while (NumberOfHighPriorityJobsPending !=0)
usleep(20);
which COULD be fine, but you should use an optimized kernel object
here to wait on.
if (WaitForSingleObject(hPriorityEvent, INFINITE) == WAIT_OBJECT) {
/// do whatever
} else {
/// Not what I expected
}
When you wait on a kernel object, you won't be spinning your thread
like you do above.
By telling you
(a) your design is bad, and why
You keep forgetting the why part.
No, you are excepting it. But its all correct.
(b) your have no idea what you are talking about
(c) you are rejecting design alternatives based on
rumor, bad memory, and hearsay
(d) you are spouting nonsense when you try to justify
your bad designs
You are not explaining with much of any reasoning why you
think that one alternative is better than another, and when
I finally do get you to explain, it is only that your
alternative is better than your misconception of my design,
not the design itself.
No, your problem is that you are stuck with a framework
Many Threads to 1 FIFO/OCR process
and everyone is telling you its flawed and why. I'm tried different
ways using your WORK LOAD which you accepted and began to change your TPS.
But you still going to overflow your Many to 1 design, especially if
you expect to use TIME to synchronize everything.
I'm not being helpful?
No not really. What you are doing is about halfway between
being helpful and pure harassment.
You are harassing this WINDOWS FORUMS with your LINUX questions!
but will fail in ways you have> not accounted
Exactly what are these ways, and precisely what have I
failed to account for?
You been told in a dozen ways why it will fail! You are OFF in your
timing of everything for the most part. You think you can achieve
what you want with a Many Thread to 1 OCR process design at the TPS
rates and work load you think you can get.
You can't!
for because of your naive belief that your fantasy
implementation is
perfect, you are going to end up with something that in
rhe real world does not actually
solve your problem in a meaningful way, and will always be
a third-rate solution that does
not scale up. I'm trying real hard to be helpful, but
like the proverbial mule, I
sometimes have to whack you solidly with a 2x4 to get your
attention.
See what I mean ALL rhetoric and no reasoning. Pure
Bullshit.
The only thing that smells is you Peter!
I know full and well that the biggest overhead of the
process is going to be disk access. I also know full and
well that tripling the number of disk access would likely
triple overhead. I am not sure that SQLite is not smart
enough to do a record number based seek without requiring an
index. Even if SQLite is not smart enough to do a record
seek without an index, it might still be fast enough.
This is what I am saying, WE TOLD YOU WHAT THE LIMITS OF SQLITE are
and you are not listening. You can do a ROW lookup, but you can't do
a low level FILE RECORD POSITION AND BYTE OFFSET like you think you
need, but really don't.
I also told you that while you UPDATE an SQLITE database, all your
READS are locked!
You refuse to comprehend that.
You convinced me that using an existing provider would tend
to result in higher reliability and/or lower development
costs. So its worth a shot trying it. If SQLite does lack
the ability to do a direct record number seek , and it is
too slow without this capability, I could always add this
feature myself.
Again, you can SELECT a row in your table using the proper query, but
it isn' a direct FILE ACCESS with BYTE OFFSET idea and again, SQLITE3
will lock your database during updates so all your REQUEST SERVER will
be locked in reading/writing any table while it is being updated by
ANYONE.
Get that thru your head.
You (and Hector) are definitely right on some things.
We are right on EVERYTHING discussed here. There has been nothing you
stated or posted that indicates any error in all suggestions to you.
You are so full of contradictions that its really is very easy for
anyone to highlight it.
You want perpetual motion in an ideal resistance-less world, but you
contradict even the goal to come close. You can't thinking that you
can do all this in, first 10ms then 20ms and you believe that
everything will be equalized serialized, ordered and naturally flow
smoothly with absolutely no processing pressures whatsoever.
The point is not that isn't a worthy endeavor but you think you can
achieve it with the more simplistic design that is the worst design
and impossible to achieve it:
IDEAL: Many Threads to Many Threads
WORST: Many Threads to 1 thread
You need somewhere to the ideal to somewhere in in between,
PRACTICAL: Many Threads to X threads
where ideal is PROVEN to not scale well after a certain amount, the
WORST is PROVEN to not work at all (not the work load you expect).
You need to focus with the common practical design PROVEN to better
performance and scale under multi-cpu or multi-core hyperthreaded
machines.
You wish to go against ALL engineering expertise and history on this.
--
HLS