[Haifux] Implementing read() like UNIX guys like it

[Nadav Har'El]

On Tue, Apr 26, 2011, Eli Billauer wrote about "Re: [Haifux] Implementing read() like UNIX guys like it":
> >(...) Second, if the CPU *did* have "something useful" to do (run other 
> >processes,
> >or whatever), it would, causing a bit more time to pass between the read()
> >and it might return more than one byte. It will only return one byte when
> >there's nothing better to do than calling read() all the time.
> >  
> That's an interesting point, but I'm not 100% sure on that one. Why 
> would the scheduler take the CPU away, if the read() operation always 
> returns one byte or two? It would, eventually take it for a while, which 
> would let data stack up, but each process would get its fair slice.

Hi,

Well, I guess that under a very specific set of circumstances (and a fairly
high throughput, on a modern CPU which can do a billion cycles a second),
the read() of one byte will take exactly the amount of time that it takes
for another byte to become ready. But when the incoming stream is slower than
that, a read() will very often block, and can cause a context switch if
other processes are waiting to run.

> I'm not saying this would cause some real degradation, but on a slow 
> embedded processor, seeing 10% CPU usage on a process which is supposed 
> to just read data...? The calculation is a 200 MHz processor, 100 kB/sec 
> and 200 CPU clocks for each byte being processed on itself.

I see. Like I said, I don't know how meaningful this "10%" figure is when
you're talking about an endless-read()-busy-loop with nothing else to do
(if there's nothing else to do, you don't care if it takes 100% cpu :-)).
If you do have other things to do - in the same thread or in a different
thread, the possibly this 10% figure would be reduced because read()s would
start returning more than 1 byte. By the way, if in your hypothetical
situation a read() takes 200 cycles to return, but the bytes arrive 2,000
cycles apart, the following read() will block, and therefore possibly cause a
context switch.

But if you have the time and energy to program that additional read delay,
then by all means, go ahead and try it. And do tell how much the difference
was noticable in the end system.

-- 
Nadav Har'El                        |      Tuesday, Apr 26 2011, 23 Nisan 5771
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Wear short sleeves! Support your right to
http://nadav.harel.org.il           |bare arms!