doc: a note about creating threads w/ same prio

[OlegHahm]

No description provided.

[haukepetersen]

honestly, I think this added text sounds a little vague. AFAIK the behavior for multiple threads with the same prio is well defined an deterministic (round robin if equal prio), right? Also, why should the number of threads be 'signifiacantly' lower than the available prio levels, isn't 'num_of_threads <= prio levels' the more precise statement here?

[cgundogan]

Could you elaborate on why it is not a good idea? Does it break priority handling? Loss of interrupts? Deadlocks?

[OlegHahm]

AFAIK the behavior for multiple threads with the same prio is well defined an deterministic (round robin if equal prio), right?

I'm not so sure about the "well defined". AFAIK it is neither well documented nor completely deterministic, in a sense that a thread with the same priority may run as long as it wants and other threads on the same priority gets only scheduled if the first thread yields or another thread with higher priority gets scheduled. Of course, this is somewhat deterministic, too - as basically any computer program is. ;-)

Also, why should the number of threads be 'significantly' lower than the available prio levels

This was not a condition, but a statement.

isn't 'num_of_threads <= prio levels' the more precise statement here?

What's the difference?

[OlegHahm]

Updated the text and tried to address your comments.

[haukepetersen]

better :-) ACK when squashed

[miri64]

May I ask, why this is added as note? Notes are added to the documentation at the very bottom, but the content seems to me important enough to be in the details section.

[OlegHahm]

Why should the note go to the bottom? (At least with my local doxygen version that doesn't happen.)

[miri64]

Oh, you're right.

[cgundogan]

backport needed?

[OlegHahm]

I don't think so, because http://doc.riot-os.org is built from master.

[miri64]

Something we might want to consider to change, as soon as the documentation is somewhat matured enough. Documentation that refers to newer versions of an API while it is recommended to use a stable version seems a little bit undesirable to me.