[En-Nut-Discussion] Unexpected thread switching

[Rob van Lieshout (PragmaLab)]

Hello Markus,

> I run an application on the EIR and Nut/OS 4.10.3 with four threads:
> idle, main, ethernet and a webserver. But when I use the functions
"fprintf" in
> the main-thread or "NutHttpProcessPostQuery" in the webserver-thread, it
> happened, that a unexpected thread switch is executed. 

Actually this isn't unexpected in case you are using a UART (or anyother
streaming device driver)  to get your string out. In case the buffer is
full, the call will end up in a yield and as soon the buffer has some room
again for the remaining part of your string, it will get notified by the OS
and execution time is given again to your UART Thread.

If this wasn't implemented this way, your fprintf() call would be blocking
and that is something you don't want. First bytes are transferred right
away, the rest is transferred in the background, that's how it works.

Which explains why some people 'solve' a deadlock in their code by adding
printf debug statements ;-) All of a sudden, the code starts working again,
due to the threadswitch which the printf introduced.

Kind regards,

Rob van Lieshout