OpenCores
URL https://opencores.org/ocsvn/openrisc_2011-10-31/openrisc_2011-10-31/trunk

Subversion Repositories openrisc_2011-10-31

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [kernel-schedcontrol.html] - Blame information for rev 174

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 28 unneback 
<!-- 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.               -->
9 
<HTML
10 
><HEAD
11 
><TITLE
12 
>Scheduler Control</TITLE
13 
><meta name="MSSmartTagsPreventParsing" content="TRUE">
14 
<META
15 
NAME="GENERATOR"
16 
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
17 
"><LINK
18 
REL="HOME"
19 
TITLE="eCos Reference Manual"
20 
HREF="ecos-ref.html"><LINK
21 
REL="UP"
22 
TITLE="The eCos Kernel"
23 
HREF="kernel.html"><LINK
24 
REL="PREVIOUS"
25 
TITLE="Spinlocks"
26 
HREF="kernel-spinlocks.html"><LINK
27 
REL="NEXT"
28 
TITLE="Interrupt Handling"
29 
HREF="kernel-interrupts.html"></HEAD
30 
><BODY
31 
CLASS="REFENTRY"
32 
BGCOLOR="#FFFFFF"
33 
TEXT="#000000"
34 
LINK="#0000FF"
35 
VLINK="#840084"
36 
ALINK="#0000FF"
37 
><DIV
38 
CLASS="NAVHEADER"
39 
><TABLE
40 
SUMMARY="Header navigation table"
41 
WIDTH="100%"
42 
BORDER="0"
43 
CELLPADDING="0"
44 
CELLSPACING="0"
45 
><TR
46 
><TH
47 
COLSPAN="3"
48 
ALIGN="center"
49 
>eCos Reference Manual</TH
50 
></TR
51 
><TR
52 
><TD
53 
WIDTH="10%"
54 
ALIGN="left"
55 
VALIGN="bottom"
56 
><A
57 
HREF="kernel-spinlocks.html"
58 
ACCESSKEY="P"
59 
>Prev</A
60 
></TD
61 
><TD
62 
WIDTH="80%"
63 
ALIGN="center"
64 
VALIGN="bottom"
65 
></TD
66 
><TD
67 
WIDTH="10%"
68 
ALIGN="right"
69 
VALIGN="bottom"
70 
><A
71 
HREF="kernel-interrupts.html"
72 
ACCESSKEY="N"
73 
>Next</A
74 
></TD
75 
></TR
76 
></TABLE
77 
><HR
78 
ALIGN="LEFT"
79 
WIDTH="100%"></DIV
80 
><H1
81 
><A
82 
NAME="KERNEL-SCHEDCONTROL">Scheduler Control</H1
83 
><DIV
84 
CLASS="REFNAMEDIV"
85 
><A
86 
NAME="AEN1784"
87 
></A
88 
><H2
89 
>Name</H2
90 
>cyg_scheduler_start, cyg_scheduler_lock, cyg_scheduler_unlock, cyg_scheduler_safe_lock, cyg_scheduler_read_lock&nbsp;--&nbsp;Control the state of the scheduler</DIV
91 
><DIV
92 
CLASS="REFSYNOPSISDIV"
93 
><A
94 
NAME="AEN1791"><H2
95 
>Synopsis</H2
96 
><DIV
97 
CLASS="FUNCSYNOPSIS"
98 
><A
99 
NAME="AEN1792"><P
100 
></P
101 
><TABLE
102 
BORDER="5"
103 
BGCOLOR="#E0E0F0"
104 
WIDTH="70%"
105 
><TR
106 
><TD
107 
><PRE
108 
CLASS="FUNCSYNOPSISINFO"
109 
>#include &lt;cyg/kernel/kapi.h&gt;
110 
        </PRE
111 
></TD
112 
></TR
113 
></TABLE
114 
><P
115 
><CODE
116 
><CODE
117 
CLASS="FUNCDEF"
118 
>void cyg_scheduler_start</CODE
119 
>(void);</CODE
120 
></P
121 
><P
122 
><CODE
123 
><CODE
124 
CLASS="FUNCDEF"
125 
>void cyg_scheduler_lock</CODE
126 
>(void);</CODE
127 
></P
128 
><P
129 
><CODE
130 
><CODE
131 
CLASS="FUNCDEF"
132 
>void cyg_scheduler_unlock</CODE
133 
>(void);</CODE
134 
></P
135 
><P
136 
><CODE
137 
><CODE
138 
CLASS="FUNCDEF"
139 
>cyg_ucount32 cyg_scheduler_read_lock</CODE
140 
>(void);</CODE
141 
></P
142 
><P
143 
></P
144 
></DIV
145 
></DIV
146 
><DIV
147 
CLASS="REFSECT1"
148 
><A
149 
NAME="KERNEL-SCHEDCONTROL-DESCRIPTION"
150 
></A
151 
><H2
152 
>Description</H2
153 
><P
154 
><TT
155 
CLASS="FUNCTION"
156 
>cyg_scheduler_start</TT
157 
> should only be called once,
158 
to mark the end of system initialization. In typical configurations it
159 
is called automatically by the system startup, but some applications
160 
may bypass the standard startup in which case
161 
<TT
162 
CLASS="FUNCTION"
163 
>cyg_scheduler_start</TT
164 
> will have to be called
165 
explicitly. The call will enable system interrupts, allowing I/O
166 
operations to commence. Then the scheduler will be invoked and control
167 
will be transferred to the highest priority runnable thread. The call
168 
will never return.
169 
      </P
170 
><P
171 
>The various data structures inside the eCos kernel must be protected
172 
against concurrent updates. Consider a call to
173 
<TT
174 
CLASS="FUNCTION"
175 
>cyg_semaphore_post</TT
176 
> which causes a thread to be
177 
woken up: the semaphore data structure must be updated to remove the
178 
thread from its queue; the scheduler data structure must also be
179 
updated to mark the thread as runnable; it is possible that the newly
180 
runnable thread has a higher priority than the current one, in which
181 
case preemption is required. If in the middle of the semaphore post
182 
call an interrupt occurred and the interrupt handler tried to
183 
manipulate the same data structures, for example by making another
184 
thread runnable, then it is likely that the structures will be left in
185 
an inconsistent state and the system will fail.
186 
      </P
187 
><P
188 
>To prevent such problems the kernel contains a special lock known as
189 
the scheduler lock. A typical kernel function such as
190 
<TT
191 
CLASS="FUNCTION"
192 
>cyg_semaphore_post</TT
193 
> will claim the scheduler lock,
194 
do all its manipulation of kernel data structures, and then release
195 
the scheduler lock. The current thread cannot be preempted while it
196 
holds the scheduler lock. If an interrupt occurs and a DSR is supposed
197 
to run to signal that some event has occurred, that DSR is postponed
198 
until the scheduler unlock operation. This prevents concurrent updates
199 
of kernel data structures.
200 
      </P
201 
><P
202 
>The kernel exports three routines for manipulating the scheduler lock.
203 
<TT
204 
CLASS="FUNCTION"
205 
>cyg_scheduler_lock</TT
206 
> can be called to claim the
207 
lock. On return it is guaranteed that the current thread will not be
208 
preempted, and that no other code is manipulating any kernel data
209 
structures. <TT
210 
CLASS="FUNCTION"
211 
>cyg_scheduler_unlock</TT
212 
> can be used to
213 
release the lock, which may cause the current thread to be preempted.
214 
<TT
215 
CLASS="FUNCTION"
216 
>cyg_scheduler_read_lock</TT
217 
> can be used to query the
218 
current state of the scheduler lock. This function should never be
219 
needed because well-written code should always know whether or not the
220 
scheduler is currently locked, but may prove useful during debugging.
221 
      </P
222 
><P
223 
>The implementation of the scheduler lock involves a simple counter.
224 
Code can call <TT
225 
CLASS="FUNCTION"
226 
>cyg_scheduler_lock</TT
227 
> multiple times,
228 
causing the counter to be incremented each time, as long as
229 
<TT
230 
CLASS="FUNCTION"
231 
>cyg_scheduler_unlock</TT
232 
> is called the same number of
233 
times. This behaviour is different from mutexes where an attempt by a
234 
thread to lock a mutex multiple times will result in deadlock or an
235 
assertion failure.
236 
      </P
237 
><P
238 
>Typical application code should not use the scheduler lock. Instead
239 
other synchronization primitives such as mutexes and semaphores should
240 
be used. While the scheduler is locked the current thread cannot be
241 
preempted, so any higher priority threads will not be able to run.
242 
Also no DSRs can run, so device drivers may not be able to service
243 
I/O requests. However there is one situation where locking the
244 
scheduler is appropriate: if some data structure needs to be shared
245 
between an application thread and a DSR associated with some interrupt
246 
source, the thread can use the scheduler lock to prevent concurrent
247 
invocations of the DSR and then safely manipulate the structure. It is
248 
desirable that the scheduler lock is held for only a short period of
249 
time, typically some tens of instructions. In exceptional cases there
250 
may also be some performance-critical code where it is more
251 
appropriate to use the scheduler lock rather than a mutex, because the
252 
former is more efficient.
253 
      </P
254 
></DIV
255 
><DIV
256 
CLASS="REFSECT1"
257 
><A
258 
NAME="KERNEL-SCHEDCONTROL-CONTEXT"
259 
></A
260 
><H2
261 
>Valid contexts</H2
262 
><P
263 
><TT
264 
CLASS="FUNCTION"
265 
>cyg_scheduler_start</TT
266 
> can only be called during
267 
system initialization, since it marks the end of that phase. The
268 
remaining functions may be called from thread or DSR context. Locking
269 
the scheduler from inside the DSR has no practical effect because the
270 
lock is claimed automatically by the interrupt subsystem before
271 
running DSRs, but allows functions to be shared between normal thread
272 
code and DSRs.
273 
      </P
274 
></DIV
275 
><DIV
276 
CLASS="NAVFOOTER"
277 
><HR
278 
ALIGN="LEFT"
279 
WIDTH="100%"><TABLE
280 
SUMMARY="Footer navigation table"
281 
WIDTH="100%"
282 
BORDER="0"
283 
CELLPADDING="0"
284 
CELLSPACING="0"
285 
><TR
286 
><TD
287 
WIDTH="33%"
288 
ALIGN="left"
289 
VALIGN="top"
290 
><A
291 
HREF="kernel-spinlocks.html"
292 
ACCESSKEY="P"
293 
>Prev</A
294 
></TD
295 
><TD
296 
WIDTH="34%"
297 
ALIGN="center"
298 
VALIGN="top"
299 
><A
300 
HREF="ecos-ref.html"
301 
ACCESSKEY="H"
302 
>Home</A
303 
></TD
304 
><TD
305 
WIDTH="33%"
306 
ALIGN="right"
307 
VALIGN="top"
308 
><A
309 
HREF="kernel-interrupts.html"
310 
ACCESSKEY="N"
311 
>Next</A
312 
></TD
313 
></TR
314 
><TR
315 
><TD
316 
WIDTH="33%"
317 
ALIGN="left"
318 
VALIGN="top"
319 
>Spinlocks</TD
320 
><TD
321 
WIDTH="34%"
322 
ALIGN="center"
323 
VALIGN="top"
324 
><A
325 
HREF="kernel.html"
326 
ACCESSKEY="U"
327 
>Up</A
328 
></TD
329 
><TD
330 
WIDTH="33%"
331 
ALIGN="right"
332 
VALIGN="top"
333 
>Interrupt Handling</TD
334 
></TR
335 
></TABLE
336 
></DIV
337 
></BODY
338 
></HTML
339 
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.