Hi Kaspar,
On 06/12/2018 11:05 PM, Kaspar Schleiser wrote:
RIOT's scheduler used to work like that: any preemption by a higher
priority thread would advance the current priority's circular runqueue.
That has been fixed years ago.
Nowadays, only if a thread calls explicit thread_yield() or it blocks,
it's "friends" will be scheduled.
Excellent!
Coroutines make it possible to program asynchronous code in a
blocking style - see "await". This is more natural and easier that
using callbacks.
How does it compare to sending / receiving messages?
Using messages is OK, but not everything is built that way. Even code
which uses a separate thread that processes messages must use locks.
Messages require some decoding logic if one is expecting messages from
many senders. I'm thinking of a loop in which one waits for messages and
acts according to the type: what would conceptually be multiple threads
gets squashed into a single chunk of code.
Assigning the same priority to two or more threads is usually not a
good idea.
Can't really argue with that, can you? ;)
More seriously, that note can definitely be improved.
I think there's no reason to discourage people from assigning many
threads the same priority. I would do it if it means I can avoid
managing locks on my threads.
In fact, I don't see why an application (user-code) can't run entirely
in one priority group.
We might consider to make even blocking of a thread not advance that
thread priority's run queue, but I'd be reluctant to change the
semantics that much. >
No, that's fine, blocking of a thread should advance the queue. That's a
core feature: a thread can block on something that depends on another
thread in the group.
Regards,
Juan.
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
