home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / research / 1082 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  3.5 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!olivea!hal.com!darkstar.UCSC.EDU!osr
  2. From: jtk@netcom.com (Jane Valencia)
  3. Newsgroups: comp.os.research
  4. Subject: Re: Microkernel for Real-Time Computing
  5. Message-ID: <1eojb2INNqr8@darkstar.UCSC.EDU>
  6. Date: 22 Nov 92 18:25:38 GMT
  7. References: <1e92s7INN8dg@darkstar.UCSC.EDU> <1ee4cgINNpsr@darkstar.UCSC.EDU>
  8. Organization: Netcom - Online Communication Services  (408 241-9760 guest)
  9. Lines: 62
  10. Approved: comp-os-research@ftp.cse.ucsc.edu
  11. NNTP-Posting-Host: ftp.cse.ucsc.edu
  12. Originator: osr@ftp
  13.  
  14. danh@quantum.qnx.com (Dan Hildebrand) writes:
  15.  
  16. >There is nothing that inherently prevents a monolithic kernel from 
  17. >providing deterministic realtime scheduling.
  18.  
  19. Agreed.  The problem in a UNIX kind of kernel is that your latency to
  20. task switch is bounded by the worst-case path length from time where
  21. your real-time process becomes runnable to the time it runs.  In classic
  22. UNIX, this the time until the current thread either explicitly sleeps
  23. or returns to user mode.
  24.  
  25. In V.4 (and HP/UX until 8.0) the kernel was enhanced (if you'll pardon
  26. the term) with "preemption points" which were simply further places
  27. in the kernel where context could be switched to a higher priority
  28. runnable process.  By inserting these points into long code paths, better
  29. (lower) latencies could be achieved.
  30.  
  31. The problem is that you have to consider every code path in the system,
  32. and you basically have to keep considering them as you make enhancements
  33. and bug fixes.  If you put a preemption point at a place where it turns
  34. out you shouldn't (because you were using a resource but didn't have
  35. it sufficiently mutexed/locked/etc.), you would add a bug to the system.
  36. Speaking from my experience with HP/UX, these bugs are not necessarily
  37. easy to find!
  38.  
  39. >> 1. What are the advantages of microkernel for real-time applications
  40. >> over a traditional monolithic kernel, and why?
  41. >A true microkernel ( not a 200 Kbyte "micro"-kernel ) can be roughly 
  42. >compared to a realtime executive in terms of complexity and performance. 
  43.  
  44. Let me spell this out explicitly.  If you have some body of code which
  45. defines the performance and latency of your system, then all other
  46. things being equal, the smaller it is, the easier it is to understand,
  47. modify, and maintain.  "Understanding" in this case relates to
  48. simple functionality, as well as latency.
  49.  
  50. >I have a paper with more details if you're interested.
  51.  
  52. I'll say he does! :-)  Very good paper, worth reading time and again.
  53.  
  54. Now, a couple imponderables:
  55.  
  56. With a "true" microkernel (like QNX), you can get a pretty good
  57. handle on latency.  What if your real-time application wants to
  58. use the filesystem?  Or some devices?  Moving code out of the kernel
  59. does not help you build a real-time system if you still depend on
  60. that code, and it is not built to support real-time features.
  61. Classic examples of this are disk sort routines which starve a
  62. single I/O from a real-time process while taking loads of new I/O's
  63. from background processes.  In this sense microkernels are a "divide
  64. and conquer" technique; you still have to conquer the individual
  65. parts.
  66.  
  67. One thing the paper on QNX I read *didn't* tell was how to handle
  68. those memory-to-memory copies.  How do you keep handles on various
  69. process' memory?  In what context do you do the copy?  If it's in the
  70. kernel, how do you go about watching for higher priority events?  If
  71. it's in the user context, how do you provide an acceptable granularity
  72. of process protection?
  73.  
  74.                     Andy Valencia
  75.                     jtk@netcom.com
  76.