As discussed in #2725, this commit renames a number of stacksize constants to
better convey their intended usage. In addition, constants for thread priority
are given a `THREAD_` prefix. Changes are:
* KERNEL_CONF_STACKSIZE_PRINTF renamed to THREAD_EXTRA_STACKSIZE_PRINTF
* KERNEL_CONF_STACKSIZE_DEFAULT renamed to THREAD_STACKSIZE_DEFAULT
* KERNEL_CONF_STACKSIZE_IDLE renamed to THREAD_STACKSIZE_IDLE
* KERNEL_CONF_STACKSIZE_MAIN renamed to THREAD_STACKSIZE_MAIN
* Move thread stacksizes from kernel.h to thread.h, since the prefix changed
* PRIORITY_MIN renamed to THREAD_PRIORITY_MIN
* PRIORITY_IDLE renamed to THREAD_PRIORITY_IDLE
* PRIORITY_MAIN renamed to THREAD_PRIORITY_MAIN
* Move thread priorities from kernel.h to thread.h since the prefix has changed
* MINIMUM_STACK_SIZE renamed to THREAD_STACKSIZE_MINIMUM for consistency
msg_send_int() sets `m->sender_pid = target_pid`. This was used to flag a
message as having been sent by an ISR.
This PR introduces a static inline function `msg_sent_by_int()` and a
specific define for this purpose.
`thread.c` initializes a thread with an empty message queue. `cib_put()`
will `return -1` for an empty CIB, so there is no need to test if
`thread->msg_array != NULL`.
Fixes#1942.
There were two instances were it was not checked the target thread has a
message queue before queuing the message.
This PR centralizes the check into `queue_msg()`.
If a thread sends blocking, but the target thread is not currently in
receive mode, the sender gets queued. If it has a higher priority it
should run again as soon as the target goes into receiving mode.
Fixes#1708.
Currently involuntary preemption causes the current thread not only to
yield for a higher prioritized thread, but all other threads of its own
priority class, too.
This PR adds the function `thread_yield_higher()`, which will yield the
current thread in favor of higher prioritized functions, but not for
threads of its own priority class.
Boards now need to implement `thread_yield_higher()` instead of
`thread_yield()`, but `COREIF_NG` boards are not affected in any way.
`thread_yield()` retains its old meaning: yield for every thread that
has the same or a higher priority.
This PR does not touch the occurrences of `thread_yield()` in the periph
drivers, because the author of this PR did not look into the logic of
the various driver implementations.
Instead of using differing integer types use kernel_pid_t for process
identifier. This type is introduced in a new header file to avoid
circular dependencies.
When setting the running task reply_blocked, it is implicitly removed
from the runqueue. But if queueing of a msg is actually successful, the
thread exits msg_send without yielding, continuing to run even if it's
not supposed to.
Nice example of why multiple function exit points lead to weird
errors...
solves issue #100
If the sender is reply-blocked, waking it up after its message has been
delivered is wrong. It needs to stay reply-blocked until the reply has
been delivered.
