home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10410 < prev    next >
Encoding:
Text File  |  1992-11-04  |  4.8 KB  |  102 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!spool.mu.edu!caen!batcomputer!rpi!psinntp!psinntp!ficc!peter
  3. From: peter@ferranti.com (peter da silva)
  4. Subject: Re: Multi uP P5 systems
  5. Message-ID: <id.PYOU.G9B@ferranti.com>
  6. Organization: Xenix Support, FICC
  7. References: <1286@taniwha.UUCP> <id.MIFU.6JC@ferranti.com> <1291@taniwha.UUCP>
  8. Date: Wed, 4 Nov 1992 17:02:12 GMT
  9. Lines: 91
  10.  
  11. In article <1291@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes:
  12. > What I really mean is where do you hold the data between when the actual IO
  13. > completes and the wait() is called .....
  14.  
  15. In the kernel. For a fairly common case where you abort the I/O on a timeout
  16. that saves you copying to process space. You also get a lot more robust
  17. implementation if you can't accidentally trash pending I/O requests.
  18.  
  19. Making the system tolerant of programming error (or more precisely, designing
  20. it to that it's easy to separate interface problems from programming problems)
  21. has saved my butt so many times I'm REALLY reluctant to move anything to user
  22. address space before the user process is ready for it.
  23.  
  24. > >Another problem with ASTs is that you either have to buffer them (reimplement
  25. > >the O/S queuing mechanism) if you have multiple waits outstanding, or
  26. > >explicitly hold them off (which if you analyse it becomes equivalent to
  27.  
  28. > ever hear of lists?
  29.  
  30. i.e. "reimplement the O/S queuing mechanism".
  31.  
  32. > >the above call in some fashion) possibly with polling (enable all ASTs,
  33. > >did anything happen? No... disable, wait, and retry).
  34.  
  35. > No you have a sleep() call that puts the process asleep untill either
  36. > it's woken up or an AST is delivered etc etc
  37.  
  38. Which is equivalent to the mechanism I'm suggesting.
  39.  
  40. > An AST driven program has a main routine that sets everything up, starts
  41. > all the I/Os and then sleeps untill everything's done - each I/O completion
  42. > starts the next I/O - for example 'cu' would have one AST reading from the
  43. > TTY and writing to the console and another reading from the console and
  44. > writing to the TTY, the main program would just open the devices, set their
  45. > modes and wait for the session to close.
  46.  
  47. Which is exactly equivalent to the mechanism I'm talking about, except you
  48. don't have to worry about library routines issuing their own sleeps (for
  49. whatever reason... open, for example, is likely to be implemented that way
  50. in a general asynchronous O/S) and then having to hold your own ASTs until
  51. you know it's safe to call the runtime. You've reduced the difficult task of
  52. writing asynchronous software to nearly as easy as writing synchronous
  53. software.
  54.  
  55. Having ASTs is useful, and occasionally necessary, but they should NOT be
  56. the normal mechanism for asynchronous I/O.
  57.  
  58. > Currently Unix systems have to make 2
  59. > processes/threads and take context switches between them to have the same
  60. > effect.
  61.  
  62. That's a red herring. I'm not talking about current UNIX implementations.
  63.  
  64. > >Using statically allocated memory is cheaper, if you're doing something for
  65. > >which this is a high cost. Then you can use your own buffering scheme (such
  66. > >as simple double buffering).
  67.  
  68. > but paged VM is even cheaper still ?
  69.  
  70. In real-time software *any* VM is a questionable design decision.
  71.  
  72. > >Actually, it's because of the way waits are designed with a sleep address
  73. > >rather than a queue. I don't think anyone else uses this particular kludge.
  74.  
  75. > No, many Unix systems either have a uio structure that's allocated on
  76. > the kernel stack (in which case the IO request can't return without 
  77. > deallocating the IO context) or the equivalent that's allocated staticly
  78. > in the U. - Systems that have threads have one of these per kernel thread
  79. > context.
  80.  
  81. That design decision was made possible by the wait-address kludge.
  82.  
  83. > Well to stop flogging a dead horse .... let's talk about sleep()/wakeup()
  84. > which I think are the Unix kernel equivalent of read()/write() in making it
  85. > easy for kernel-neophytes to start kernel programming - these synchronization
  86. > primitivtes are very forgiving compared with semaphores etc (sort of like
  87. > a shotgun compared with a rifle :-) On the bad side they are sometimes rather
  88. > slow - and not always fair .... 
  89.  
  90. Well, I think a better way to make kernel programming easier is to build the
  91. system as a microkernel. Then a "kernel" process (driver, file system, and
  92. so on) differs only in authorisation from a user process, and you can make
  93. all the same calls from it. This has proven spectacularly successful in the
  94. Amiga (which is a baby microkernel design, since it doesn't use memory
  95. protection), with hobbyist-written drivers and file systems coming out very
  96. early in the freeware cycle.
  97. -- 
  98. % Peter da Silva % 77487-5012 % +1 713 274 5180 % Har du kramat din varg idag?
  99. /M{moveto}def/H{newpath 0 19 M 0 6 R 4 -4 R 0 16 M 5 0 R 3 -3 R -4 0 R -3 3 R 8
  100. 8 M 0 5 R stroke}def/R{rlineto}def 24 24 scale 3 3 translate H newpath 10 6 M 2
  101. 2 R -4 0 R closepath stroke 20 0 translate -1 1 scale H showpage %    `-_-'
  102.