Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case
On Fri, 7 Apr 2017 08:29:08 -0700
Andy Ross <email@example.com> wrote:
Paul Sokolovsky <firstname.lastname@example.org> wrote (on Thursday,Thanks for the reply. The original hunch was that there was some kind
of issue with the scheduling implementation. I explained where it came
from - because other explanations, like "fast thread can't keep up with
slow ISR" or "the problem is in UART handling" seemed to be too simple
an answer and thus unrealistic to be true. It more and more looks like
I was wrong, and the issue lies on UART handling side, and is a
relatively obvious to be looked at and ignored :-/.
to handle the bytes arriving at the line rate (maybeSpeculatively, yes - they go into busy-polling implementation of UART
TX. And as mentioned in my previous email, we always spend more cycles
to send a char (because of the overheads we do besides send), than to
receive, so with busy-polling send, we'll never get a reliable behavior.
I mean... I know you don't want to hear this but the situation youSo, either everyone does wrong, or people save on wires because they
aren't needed in prevalent number of modern usecases.
Or if you can, adjust the protocol toRight, the last one is 2nd most popular workaround nowadays - almost
all protocols are request-response, and require response much sooner
than after sending a megabyte of data, but some do send many kilobytes
nonetheless. The 1st workaround is still just handling a UART with a
fast CPU such that flow control issues aren't hit in the realistic
scenarios. "Realistic scenarios" include being able to paste a dozen of
lines in an echoing application. That works in many systems
- why don't we target Zephyr being able to do that too?
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog