home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / realtime / 1482 < prev    next >
Encoding:
Text File  |  1992-12-28  |  2.1 KB  |  49 lines
  1. Newsgroups: comp.realtime
  2. Path: sparky!uunet!portal!quadsys!roland
  3. From: roland@quadsys.com (Roland Besserer)
  4. Subject: Re: Real_time systems
  5. Message-ID: <Bzy362.zo@quadsys.com>
  6. Organization: QUAD Systems
  7. X-Newsreader: Tin 1.1 PL3
  8. References: <1992Dec22.041024.25911@megadata.mega.oz.au>
  9. Date: Mon, 28 Dec 1992 01:08:25 GMT
  10. Lines: 37
  11.  
  12. andrew@megadata.mega.oz.au (Andrew McRae) writes:
  13. : The complexity of these systems is mostly (I say again, *mostly*,
  14. : not *always*) unwarranted and often add to the overall cost
  15. : of the system (in terms of memory, CPU, software cost etc.)
  16. : In the truly embedded world, it is often better to simplify
  17. : the OS and make the processes/tasks running under it `co-operative',
  18. : so that timing contracts are met.
  19. : 
  20. : .... (deleted)
  21. :
  22. : I have come to the conclusion that preemption is to be
  23. : avoided *if at all possible*, since it carries a lot of
  24. : baggage with it. But having said all that, it certainly
  25. : has its place outside of the hard real time world, especially
  26. : in systems that require some aspects of real time behaviour, such
  27. : as responding quickly to user input, yet sharing CPU resources
  28. : fairly amongst competing processes, where some processes are considered
  29. : higher priority (e.g the X server responding to mouse/keyboard events,
  30. : yet while processing large bit images). Threads will help a lot.
  31. : 
  32. One of the best postings on the subject. Although I agree with your 
  33. statements and conclusions I think it's worthwhile pointing out the
  34. cooperative task approach is only really suitable in fairly simple
  35. real-time designs. Increasingly complex and particularly highly dynamic
  36. designs, requiring constant code/task modification, are typically better
  37. coded using a flexible real-time kernel that employs pre-emption,
  38. scheduling, priorities, etc.
  39.  
  40. Yes, you will pay a price: overall performance penalties, increase in
  41. basic resource requirments, increased software costs, etc. But complex designs
  42. are much easier to maintain in such an environment and software coding and
  43. maintanability become primary concerns.
  44. -- 
  45.  
  46. Roland Besserer
  47. QUAD Systems
  48. roland@quadsys.com
  49.