Re: Can extra processing threads help in this case?
Joseph M. Newcomer wrote:
DWORD t1 = GetTickCount();
Sleep(1); // sleep 1 millisecond
Actually, this is EXACTLY the same as writing Sleep(15);
You did not read further.
DWORD t2 = GetTickCount();
This is meaningless, because it is subject to what is called "gating error". While
generally you will see the difference as being 15ms, it really deals with how the timer
tick count is updated relative to the scheduler. I do not believe this is defined.
Whats meaningless? The difference showing that it will not be 1 ms
sleep? No generally, always! The only way to change that is by using
the multi-media timers, see timeBeginPeriod() which allows you to set
the greatest resolution possible for the hardware - 1 ms. That still
doesn't change your quantum.
What it means is that in a code that does not do any preemption on its
own (which will slow it down), just natural code, the CPU and OS will
preempt you every QUANTUM.
Not quite true. It is actually far more complex and subtle than this.
It is very true Joe, and for pedro its good enough to show the key
point that his dream of a complete transaction time of 10 ms is below
For example, if
there is anothef compute-bound interactive thread running, you will get quite different
numbers. And if you create the following app
and run it at priority 15, you will get some really UGLY results when you run your above
example at normal priority.
Right because if there is no other equal priority threads, the OS will
immediately make it active again producing a very high context
But we are talking about equal priority threads, regardless of class,
no preemption on your part, natural op-code quantum based switches
which the scheduler will attempt to provide equal time slicing to
equal priority threads - period. Nothing untrue about that.
Anyway, the main point is that even with pure code, no hardware
interrupts, which he won't be able to avoid anyway, no sleeps, nothing
that perpetuates context switching, purely natural quantum based
switching, I doubt his OCR code is that fast to complete in less than
He's totally unrealistic.