home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / programm / 3315 < prev    next >
Encoding:
Text File  |  1992-12-13  |  4.6 KB  |  104 lines
  1. Newsgroups: comp.programming
  2. Path: sparky!uunet!wupost!sdd.hp.com!think.com!ames!agate!linus!linus.mitre.org!boole.mitre.org!crawford
  3. From: crawford@boole.mitre.org (Randy Crawford)
  4. Subject: Re: reentrant code
  5. Message-ID: <1992Dec13.051634.14815@linus.mitre.org>
  6. Sender: news@linus.mitre.org (News Service)
  7. Nntp-Posting-Host: boole.mitre.org
  8. Organization: The MITRE Corporation, McLean, VA
  9. References: <GARY.92Dec9104702@kuwait.gdfwc3> <1992Dec10.045716.12505@linus.mitre.org> <dak.724201089@messua>
  10. Date: Sun, 13 Dec 1992 05:16:34 GMT
  11. Lines: 91
  12.  
  13. In article <dak.724201089@messua> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:
  14. >crawford@boole.mitre.org (Randy Crawford) writes:
  15. >
  16. >>In article <GARY.92Dec9104702@kuwait.gdfwc3> gdfwc3!gary@uunet.uu.net writes:
  17. >>>What are the requirements for code to be reentrant?  When can
  18. >>>non-reentrant code hurt you?  Can someone recommend a good reference
  19. >>>on this subject?
  20. >
  21. >>Reentrant code must allow more than one task to concurrently execute the
  22. >>same instructions in the same memory space.  If one thread of execution makes 
  23. >>use of data which is the same data used by another thread, a possibility 
  24. >>exists for one thread to overwrite the data written by the other.  [...] 
  25.  
  26. >The problems of reentrancy are a bit different from concurrency. 
  27.  
  28. True, but reentrancy is irrelevant unless concurrency in some form (like
  29. context switching) is involved.
  30.  
  31. >Reentrancy
  32. >may be a subject in system programming, because any subroutine an
  33. >interrupt routine uses must work without disturbing an instance of
  34. >the routine active before the interrupt. You can do that by saving all
  35. >variables on some stack, restoring them afterward. Z80 Versions of Turbo
  36. >Pascal did just that with local variables, because variables on the
  37. >stack were not especially supported by the processor.a
  38.  
  39. Certainly reentrancy does not require that you save all variables on the 
  40. stack, but I believe that is generally how it is managed today in most OSs
  41. and PLs.
  42.  
  43. >
  44. >This technique is still there in interrupt routines saving all REGISTERS
  45. >they might use.
  46. >
  47. >Note that this reentrancy scheme works fine with interrupts as well as
  48. >with recursions, with the latter NOT if you pass any variables of the
  49. >recursion by reference.
  50.  
  51. To each iteration of a function, reference arguments _are_ global variables.
  52.  
  53. >
  54. >It does not work with concurrency.
  55.  
  56. I did not mean to equate concurrency with reentrancy, but to point out that
  57. reentrancy is inextricably linked with some form of concurrency, otherwise
  58. reentrancy is unnecessary to protect data vulnerable to the form of
  59. `concurrnncy' known as context switching.
  60.  
  61. >
  62. >Reentrancy is also not merely a hidden OS-matter, at least not in Unix,
  63. >because signal handlers may not use nonreentrant routines they might
  64. >have interrupted.
  65.  
  66. A signal handler is meaningful only as a form of context switch, and is 
  67. solely an OS matter.  That the PL allows you to write callback routines
  68. for the OS doesn't make them separate from the OS -- they simply extend it.
  69.  
  70. >
  71. >And the sticky bit is an entirely different thing. In older versions of
  72. >Unix, it told the system that execution of a program was likely to
  73. >occur that often, that the system better keep a copy of the program
  74. >in the swap area. Note that in this blissful old time, EVERY program
  75. >was allocated in the swap area. So the fork() system call was pretty
  76. >simple: it swapped the process, but did not invalidate the copy in core.
  77.  
  78. In principle, I agree that the sticky bit differs from reentrancy, and that
  79. its original use is effectively obsolete, given the evolution of VM in Unix.  
  80. But in practice, I suspect that those who still program for it have come to 
  81. employ it in lieu of shared libraries.  (Yes, this is hypothetical.  I've 
  82. yet to hear of anyone write code to use the sticky bit.)  Shared libraries 
  83. are necessarily reentrant (to be at all reliable), and there's no reason
  84. that a program couldn't be designed to use its sticky bit to avail the 
  85. system of a suite of resident reentrant services if that OS does not support 
  86. shared libraries.
  87.  
  88. >
  89. >I cannot rule out all possibility that this copy might have had an
  90. >already altered
  91. >data area, and so the programs with sticky bit would have to be reentrant
  92. >on systems not supporting shared text. But I believe in the sanity of
  93. >the early Unix system designers.
  94. >
  95. >By the way, concurrency or multithreadability is important for shared
  96. >libraries.
  97.  
  98. Agreed, on both counts.
  99. -- 
  100.  
  101. | Randy Crawford        crawford@mitre.org        The MITRE Corporation
  102. |                                                 7525 Colshire Dr., MS Z421
  103. | N=1 -> P=NP           703 883-7940              McLean, VA  22102
  104.