1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Thread control</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="The eCos Kernel"
23 HREF="kernel.html"><LINK
25 TITLE="Thread information"
26 HREF="kernel-thread-info.html"><LINK
28 TITLE="Thread termination"
29 HREF="kernel-thread-termination.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="kernel-thread-info.html"
71 HREF="kernel-thread-termination.html"
82 NAME="KERNEL-THREAD-CONTROL">Thread control</H1
90 >cyg_thread_yield, cyg_thread_delay, cyg_thread_suspend, cyg_thread_resume, cyg_thread_release -- Control whether or not a thread is running</DIV
92 CLASS="REFSYNOPSISDIV"
108 CLASS="FUNCSYNOPSISINFO"
109 >#include <cyg/kernel/kapi.h>
118 >void cyg_thread_yield</CODE
125 >void cyg_thread_delay</CODE
126 >(cyg_tick_count_t delay);</CODE
132 >void cyg_thread_suspend</CODE
133 >(cyg_handle_t thread);</CODE
139 >void cyg_thread_resume</CODE
140 >(cyg_handle_t thread);</CODE
146 >void cyg_thread_release</CODE
147 >(cyg_handle_t thread);</CODE
161 >These functions provide some control over whether or not a particular
162 thread can run. Apart from the required use of
165 >cyg_thread_resume</TT
166 > to start a newly-created
167 thread, application code should normally use proper synchronization
168 primitives such as condition variables or mail boxes.
181 >cyg_thread_yield</TT
182 > allows a thread to relinquish
183 control of the processor to some other runnable thread which has the
184 same priority. This can have no effect on any higher-priority thread
185 since, if such a thread were runnable, the current thread would have
186 been preempted in its favour. Similarly it can have no effect on any
187 lower-priority thread because the current thread will always be run in
188 preference to those. As a consequence this function is only useful
189 in configurations with a scheduler that allows multiple threads to run
190 at the same priority, for example the mlqueue scheduler. If instead
191 the bitmap scheduler was being used then
194 >cyg_thread_yield()</TT
195 > would serve no purpose.
198 >Even if a suitable scheduler such as the mlqueue scheduler has been
201 >cyg_thread_yield</TT
203 prove useful: instead timeslicing will be used to ensure that all
204 threads of a given priority get a fair slice of the available
205 processor time. However it is possible to disable timeslicing via the
206 configuration option <TT
208 >CYGSEM_KERNEL_SCHED_TIMESLICE</TT
212 >cyg_thread_yield</TT
214 implement a form of cooperative multitasking.
227 >cyg_thread_delay</TT
228 > allows a thread to suspend until
229 the specified number of clock ticks have occurred. For example, if a
230 value of 1 is used and the system clock runs at a frequency of 100Hz
231 then the thread will sleep for up to 10 milliseconds. This
232 functionality depends on the presence of a real-time system clock, as
233 controlled by the configuration option
236 >CYGVAR_KERNEL_COUNTERS_CLOCK</TT
240 >If the application requires delays measured in milliseconds or similar
241 units rather than in clock ticks, some calculations are needed to
242 convert between these units as described in <A
243 HREF="kernel-clocks.html"
245 >. Usually these calculations can be done by
246 the application developer, or at compile-time. Performing such
247 calculations prior to every call to
250 >cyg_thread_delay</TT
251 > adds unnecessary overhead to the
261 >Suspend and Resume</H2
263 >Associated with each thread is a suspend counter. When a thread is
264 first created this counter is initialized to 1.
267 >cyg_thread_suspend</TT
268 > can be used to increment the
269 suspend counter, and <TT
271 >cyg_thread_resume</TT
273 it. The scheduler will never run a thread with a non-zero suspend
274 counter. Therefore a newly created thread will not run until it has
278 >An occasional problem with the use of suspend and resume functionality
279 is that a thread gets suspended more times than it is resumed and
280 hence never becomes runnable again. This can lead to very confusing
281 behaviour. To help with debugging such problems the kernel provides a
285 >CYGNUM_KERNEL_MAX_SUSPEND_COUNT_ASSERT</TT
287 imposes an upper bound on the number of suspend calls without matching
288 resumes, with a reasonable default value. This functionality depends
289 on infrastructure assertions being enabled.
298 >Releasing a Blocked Thread</H2
300 >When a thread is blocked on a synchronization primitive such as a
301 semaphore or a mutex, or when it is waiting for an alarm to trigger,
302 it can be forcibly woken up using
305 >cyg_thread_release</TT
306 >. Typically this will call the
307 affected synchronization primitive to return false, indicating that
308 the operation was not completed successfully. This function has to be
309 used with great care, and in particular it should only be used on
310 threads that have been designed appropriately and check all return
311 codes. If instead it were to be used on, say, an arbitrary thread that
312 is attempting to claim a mutex then that thread might not bother to
313 check the result of the mutex lock operation - usually there would be
314 no reason to do so. Therefore the thread will now continue running in
315 the false belief that it has successfully claimed a mutex lock, and
316 the resulting behaviour is undefined. If the system has been built
317 with assertions enabled then it is possible that an assertion will
318 trigger when the thread tries to release the mutex it does not
324 >cyg_thread_release</TT
326 POSIX compatibility layer, where it is used in the implementation of
327 per-thread signals and cancellation handlers.
333 NAME="KERNEL-THREAD-CONTROL-CONTEXT"
340 >cyg_thread_yield</TT
341 > can only be called from thread
342 context, A DSR must always run to completion and cannot yield the
343 processor to some thread. <TT
345 >cyg_thread_suspend</TT
349 >cyg_thread_resume</TT
353 >cyg_thread_release</TT
354 > may be called from thread or
363 SUMMARY="Footer navigation table"
374 HREF="kernel-thread-info.html"
392 HREF="kernel-thread-termination.html"
402 >Thread information</TD
416 >Thread termination</TD