home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / arch / 12060 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  4.2 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!igor.rutgers.edu!zodiac.rutgers.edu!leichter
  2. From: leichter@zodiac.rutgers.edu
  3. Newsgroups: comp.arch
  4. Subject: Re: reentrant
  5. Message-ID: <1993Jan4.095245.1@zodiac.rutgers.edu>
  6. Date: 4 Jan 93 14:52:45 GMT
  7. References: <id.JY9W.Y64@ferranti.com> <C04zn2.A95.2@cs.cmu.edu> <1993Jan2.122544.26198@sei.cmu.edu> <C08qF4.Knz@news.iastate.edu>
  8. Sender: news@igor.rutgers.edu
  9. Organization: Rutgers University Department of Computer Science
  10. Lines: 78
  11. Nntp-Posting-Host: pisces.rutgers.edu
  12.  
  13. In article <C08qF4.Knz@news.iastate.edu>, john@iastate.edu (John Hascall)
  14. writes:
  15. > }>The OS world is moving towards multithreading...
  16. > 
  17. > ...
  18. > Perhaps the research world has been...
  19. > But as far as (popular) commercially available OSes, it would seem not:
  20. > 
  21. >   MS-DOS:  not a chance
  22. >      VMS:  nope
  23.  
  24. The story for VMS is complicated, and an excellent illustration of why
  25. "yes/no" questions can be misleading.
  26.  
  27. There are two senses in which VMS has had something very much like threads
  28. from the beginning.  First, a VMS process has embedded within it four streams
  29. of control, one at each access mode (user, supervisor, executive, kernel).
  30. In the modern sense, these are "threads" in the sense that they have separate
  31. sets of registers, separate PC's, and separate stacks, all within one address
  32. space.  However, they are NOT full threads because they from a strict hierar-
  33. chy, and each access mode, in running, blocks the scheduling of the modes
  34. "outside" it.  Also, in practice, inner-mode "threads" don't really suspend
  35. themselves "at" a PC to allow outer-mode threds to run; they just stop.  When
  36. re-activated from outer modes, they generally start from a fixed PC.  How-
  37. ever, this is not a complete description, because of the second feature,
  38. AST's.
  39.  
  40. AST's (Asynchronous System Traps) are software interrupts.  Each access mode
  41. really splits into two threads, the "normal" level and the "AST" level.
  42. Code running at "normal" level can be interrupted by delivery of an AST,
  43. which then runs at "AST" level, and cannot be further interrupted (except by
  44. code at an inner mode).
  45.  
  46. It is quite possible - and common, in high-performance, interrupt-driven code
  47. - to have all of the work done within AST routines; the "normal" code just
  48. sleeps.  The result looks very much like code written for a system with
  49. threads.  It's not identical, and it's less general; but it's been there
  50. since the late '70's.
  51.  
  52. AST's get hardware support on the VAX, in the form of a "pending AST mode"
  53. register and a check by hardware whenever the access mode becomes less
  54. privileged to see if some previously-blocked AST should now be delivered.
  55. On the Alpha, the VMS PALcode services include AST support.
  56.  
  57. Essentially all system services in VMS that might block have an asynchronous
  58. form.  (The exceptions, some recently "fixed", have to do with things like
  59. opening - not reading, just opening - files.)  The asynchronous forms can
  60. either just set a flag on completion, or deliver an AST (in the form of a call
  61. to a user-specified procedure, passing a user-specified argument).  It is
  62. extremely easy to build threads on top of these services - I did it years
  63. ago, and others have, too - including DEC, for their ADA implementations
  64. among other things.
  65.  
  66. Unfortunately, the asynchronous options of the underlying services are usually
  67. not accessible from various programming language interfaces - e.g., the C or
  68. FORTRAN I/O libraries have synchronous semantics.
  69.  
  70. VMS has also had something called PPL (Parallel Programming Library) as an
  71. official part of the OS for about five years.  PPL is a thread-like package
  72. built on top of multiple processes.  The cooperating processes share SOME
  73. of their memory:  They all execute the same code, and they can allocate
  74. memory from a common heap, but they can also have private heaps.  Threads,
  75. processes, or something else?
  76.  
  77. There's a spec for a supported true threads package for VMS (and OSF); I
  78. don't think it's officially out yet for VMS, but it's been promised.
  79.  
  80. All of which makes Mr. Hascall's distinction:
  81.  
  82. >      VMS:  nope
  83. >     UNIX:  not yet
  84.  
  85. rather curious.
  86.  
  87. (BTW, the earliest thread package, complete in the modern sense, that I know
  88. of in a commercial operating system was in VAX ELN, a real-time OS for VAXes
  89. that DEC has sold since about 1983.)
  90.                             -- Jerry
  91.