Lines Matching +full:extra +full:- +full:wait +full:- +full:time
6 The kernel's priority-based scheduler allows an application's threads
13 at any point in time; this thread is known as the **current thread**.
15 There are various points in time when the scheduler is given an
19 - transition of a thread from running state to a suspended or waiting
21 - transition of a thread to the :ref:`ready state <thread_states>`, for
23 - return to thread context after processing an interrupt
24 - when a running thread invokes :c:func:`k_yield`
43 However, when both earliest-deadline-first scheduling is enabled
46 to have the higher priority. Thus, when earliest-deadline-first scheduling is
54 at any time unless interrupts have been masked. This applies to both
62 * Simple linked-list ready queue (:kconfig:option:`CONFIG_SCHED_DUMB`)
65 very fast constant time performance for single threads and very low code size.
68 the queue at any given time. On most platforms (that are not otherwise using
74 rather slower constant-time insertion and removal overhead, and on most
76 an extra ~2kb of code. The resulting behavior will scale cleanly and
82 * Traditional multi-queue ready queue (:kconfig:option:`CONFIG_SCHED_MULTIQ`)
91 O(1) time in almost all circumstances with very low constant factor. But it
115 * Simple linked-list wait_q (:kconfig:option:`CONFIG_WAITQ_DUMB`)
117 When selected, the wait_q will be implemented with a doubly-linked list.
121 Cooperative Time Slicing
135 the CPU from time to time to permit other threads to execute.
146 time period. Ready threads of *all* priorities are then allowed to execute;
151 Preemptive Time Slicing
166 time slicing (as described above), or the scheduler's time slicing capability
172 The scheduler divides time into a series of **time slices**, where slices
173 are measured in system clock ticks. The time slice size is configurable,
176 At the end of every time slice, the scheduler checks to see if the current
184 time slicing, and are never preempted by a thread of equal priority.
185 This allows an application to use preemptive time slicing
186 only when dealing with lower priority threads that are less time-sensitive.
189 The kernel's time slicing algorithm does *not* ensure that a set
190 of equal-priority threads receive an equitable amount of CPU time,
191 since it does not measure the amount of time a thread actually gets to
193 for longer than a single time slice without being required to yield.
209 becomes the current thread, its non-preemptible status is maintained.
222 for a specified time period. During the time the thread is sleeping
239 A thread can call :c:func:`k_busy_wait` to perform a ``busy wait``
240 that delays its processing for a specified time period
243 A busy wait is typically used instead of thread sleeping
250 Use cooperative threads for device drivers and other performance-critical work.
255 Use preemptive threads to give priority to time-sensitive processing
256 over less time-sensitive processing.
289 .. code-block:: c
302 /* wait for semaphore from ISR, then do related work */
306 /* wait for ISR to trigger work to perform */
325 occur between the time the semaphore is taken, finding out it is not available
331 .. code-block:: c
349 * Wait for semaphore from ISR; if acquired, do related work, then
373 idling the CPU to wait for an event. See example above.
378 .. code-block:: c