Getting Started with QNX Neutrino - QNX Software Systems

More documents

Recommendations

Info

Threads and processes © 2009, QNX Software Systems GmbH & Co. KG. Threads and processes Why processes? Let’s return to our discussion of threads and processes, this time from the perspective of a real live system. Then, we’ll take a look at the function calls used to deal with threads and processes. We know that a process can have one or more threads. (A process that had zero threads wouldn’t be able to do anything — there’d be nobody home, so to speak, to actually perform any useful work.) A Neutrino system can have one or more processes. (The same discussion applies — a Neutrino system with zero processes wouldn’t do anything.) So what do these processes and threads do? Ultimately, they form a system —a collection of threads and processes that performs some goal. At the highest level, the system consists of a number of processes. Each process is responsible for providing a service of some nature — whether it’s a filesystem, a display driver, data acquisition module, control module, or whatever. Within each process, there may be a number of threads. The number of threads varies. One designer using only one thread may accomplish the same functionality as another designer using five threads. Some problems lend themselves to being multi-threaded, and are in fact relatively simple to solve, while other processes lend themselves to being single-threaded, and are difficult to make multi-threaded. The topic of designing with threads could easily occupy another book — we’ll just stick with the basics here. So why not just have one process with a zillion threads? While some OSes force you to code that way, the advantages of breaking things up into multiple processes are many: • decoupling and modularity • maintainability • reliability The ability to “break the problem apart” into several independent problems is a powerful concept. It’s also at the heart of Neutrino. A Neutrino system consists of many independent modules, each with a certain responsibility. These independent modules are distinct processes. The people at QSS used this trick to develop the modules in isolation, without the modules relying on each other. The only “reliance” the modules would have on each other is through a small number of well-defined interfaces. This naturally leads to enhanced maintainability, thanks to the lack of interdependencies. Since each module has its own particular definition, it’s reasonably easy to fix one module — especially since it’s not tied to any other module. Reliability, though, is perhaps the most important point. A process, just like a house, has some well-defined “borders.” A person in a house has a pretty good idea when 26 Chapter 1 • Processes and Threads April 30, 2009
© 2009, QNX Software Systems GmbH & Co. KG. Threads and processes they’re in the house, and when they’re not. A thread has a very good idea — if it’s accessing memory within the process, it can live. If it steps out of the bounds of the process’s address space, it gets killed. This means that two threads, running in different processes, are effectively isolated from each other. Memory protection barrier Process 1 Process 2 Process 1's address space Process 2's address space Memory protection. Starting a process The process address space is maintained and enforced by Neutrino’s process manager module. When a process is started, the process manager allocates some memory to it and starts a thread running. The memory is marked as being owned by that process. This means that if there are multiple threads in that process, and the kernel needs to context-switch between them, it’s a very efficient operation — we don’t have to change the address space, just which thread is running. If, however, we have to change to another thread in another process, then the process manager gets involved and causes an address space switch as well. Don’t worry — while there’s a bit more overhead in this additional step, under Neutrino this is still very fast. Let’s now turn our attention to the function calls available to deal with threads and processes. Any thread can start a process; the only restrictions imposed are those that stem from basic security (file access, privilege restrictions, etc.). In all probability, you’ve already started other processes; either from the system startup script, the shell, or by having a program start another program on your behalf. Starting a process from the command line For example, from the shell you can type: $ program1 This instructs the shell to start a program called program1 and to wait for it to finish. Or, you could type: $ program2 & This instructs the shell to start program2 without waiting for it to finish. We say that program2 is running “in the background.” April 30, 2009 Chapter 1 • Processes and Threads 27
Page 1 and 2: QNX Neutrino RTOS Getting Started w
Page 3 and 4: Contents About This Guide xi What y
Page 5 and 6: © 2009, QNX Software Systems GmbH
Page 9 and 10: List of Figures A process as a cont
Page 11: About This Guide April 30, 2009 Abo
Page 14 and 15: Typographical conventions © 2009,
Page 17: Foreword to the First Edition by Pe
Page 27: © 2009, QNX Software Systems GmbH
Page 41: © 2009, QNX Software Systems GmbH
Page 93 and 94:
© 2009, QNX Software Systems GmbH
Page 95:
Chapter 2 Message Passing In this c
Page 98 and 99:
Message passing and client/server
Page 100 and 101:
Message passing and client/server
Page 102 and 103:
Multiple threads © 2009, QNX Softw
Page 104 and 105:
Multiple threads © 2009, QNX Softw
Page 106 and 107:
Using message passing © 2009, QNX
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Pulses © 2009, QNX Software System
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Message passing over a network © 2
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Priority inheritance © 2009, QNX S
Page 148 and 149:
Priority inheritance © 2009, QNX S
Page 151:
Chapter 3 Clocks, Timers, and Getti
Page 154 and 155:
Clocks and timers © 2009, QNX Soft
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Using timers © 2009, QNX Software
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Advanced topics © 2009, QNX Softwa
Page 178 and 179:
Page 180 and 181:
Page 183:
Chapter 4 Interrupts In this chapte
Page 186 and 187:
Neutrino and interrupts © 2009, QN
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Writing interrupt handlers © 2009,
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
Page 200 and 201:
TIME TIME Writing interrupt handler
Page 202 and 203:
Page 204 and 205:
Summary © 2009, QNX Software Syste
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
Page 213 and 214:
Page 215 and 216:
Page 217 and 218:
Page 219 and 220:
Page 221 and 222:
Page 223 and 224:
Page 225 and 226:
Page 227 and 228:
Page 229 and 230:
Page 231 and 232:
Page 233 and 234:
Page 235 and 236:
Page 237 and 238:
Page 239 and 240:
Page 241 and 242:
Page 243 and 244:
Page 245 and 246:
Page 247 and 248:
Page 249 and 250:
Page 251 and 252:
Page 253 and 254:
Page 255 and 256:
Page 257 and 258:
Page 259 and 260:
Page 261 and 262:
Page 263 and 264:
Page 265 and 266:
Page 267 and 268:
Page 269 and 270:
Page 271 and 272:
Page 273 and 274:
Page 275 and 276:
Page 277 and 278:
Page 279 and 280:
Page 281 and 282:
Page 283 and 284:
Page 285 and 286:
Page 287 and 288:
Page 289 and 290:
Page 291 and 292:
Page 293 and 294:
Page 295 and 296:
Page 297 and 298:
Page 299:
Page 303 and 304:
Page 305 and 306:
Page 307 and 308:
Page 309 and 310:
Page 311 and 312:
Page 313 and 314:
Page 315 and 316:
Page 317 and 318:
Page 319:
Appendix B Calling 911 In this appe
Page 322 and 323:
Seeking professional help © 2009,
Page 324 and 325:
Seeking professional help © 2009,
Page 327:
Appendix C Sample Programs In this
Page 330 and 331:
atoz.c © 2009, QNX Software System
Page 332 and 333:
atoz.c © 2009, QNX Software System
Page 334 and 335:
time1.c © 2009, QNX Software Syste
Page 336 and 337:
time1.c © 2009, QNX Software Syste
Page 338 and 339:
tp1.c © 2009, QNX Software Systems
Page 340 and 341:
tt1.c © 2009, QNX Software Systems
Page 343 and 344:
Page 345 and 346:
Page 347 and 348:
Page 349 and 350:
Page 351 and 352:
Index ! /dev/null resource manager
Page 353 and 354:
Page 355 and 356:
Page 357 and 358:
Page 359 and 360:
Page 361 and 362:
Page 363 and 364:
Page 365 and 366:
Page 367 and 368:
Page 369 and 370:
Page 371 and 372:
Page 373 and 374:
Page 375 and 376:
Page 377 and 378:
Page 379 and 380:
Page 381 and 382:
Page 383 and 384:
Page 385 and 386:
Page 387 and 388:
show all

Getting Started with QNX Neutrino - QNX Software Systems

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?