home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8219 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.8 KB  |  60 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!mcsun!Germany.EU.net!nixpbe!uranium!josef
  3. From: Josef Moellers <mollers.pad@sni.de>
  4. Subject: Re: Symmetric MP
  5. Sender: josef@nixpbe.sni.de (Moellers)
  6. Message-ID: <josef.711890540@uranium>
  7. Date: Thu, 23 Jul 1992 11:22:20 GMT
  8. References: <1992Jul17.183501.26138@decuac.dec.com> <147gceINN43d@early-bird.think.com> <BrKMq3.6D4@acsu.buffalo.edu> <1992Jul18.151923.211432@cs.cmu.edu>
  9. Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany
  10. Lines: 48
  11.  
  12. In <1992Jul18.151923.211432@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
  13.  
  14.  
  15. >pjg@acsu.buffalo.edu (Paul Graham) writes:
  16. >>i'm actually more interested in why it's apparently hard to do right
  17.  
  18. >It is harder to do than it often looks on paper. This is partly
  19. >because a kernel can have a lot of locks, and a lot of possible
  20. >sequences of events, and the interactions get you. So, complexity,
  21. >and debugging.
  22.  
  23. >Another major reason SMP takes time to achieve, is that almost
  24. >everyone seems to start from scratch. Back in the PDP-11 days, Unix
  25. >locking consisted of turning off interrupts whenever the kernel was
  26. >entered.
  27.  
  28. This is not entirely true. Interrupts were (are) still enabled, only
  29. task-switching was (is) disabled. Therefore, critical regions could (can)
  30. only exist when datastructures could (can) be accessed by "normal" kernel
  31. functions and interrupt code. These accesses were (are) protected by
  32. "spl"-calls which raise(d) the interrupt level of the processor thereby
  33. effectively locking out interrupts FROM THIS PARTICULAR INTERRUPT SOURCE
  34. (and all sources that had lower priority).
  35. I've put past and present tenses, because a lot of single-processor UN*X
  36. systems still work this way nowadays.
  37.  
  38. >      A perfectly good decision, in its day. However, the legacy
  39. >is that the kernel code became a bit of a trackless wilderness, where
  40. >it wasn't clear what was shared and by whom.  For historical reasons,
  41. >a large number of groups have *indepentantly* MP-ified this
  42. >wilderness. Well, OSF used Encore/Mach ... but who else didn't roll
  43. >their own? It's as bad as this mad desire to define one's own bus,
  44. >but with longer timelines.
  45.  
  46. It's the old problem of "not invented here" combined with "If You want
  47. my code, You pay for it".
  48. In the early days of UN*X, source code flowed quite freely between
  49. interested parties (modtly universities and other ersearch institutes),
  50. because there was no commercial interest. Nowadays every single idea to
  51. "enhance" UN*X spells "$$$", so everyone wanting to do MP will have to
  52. roll their own dice.
  53.  
  54. >-- 
  55. >Don        D.C.Lindsay     Carnegie Mellon Computer Science
  56. -- 
  57. | Josef Moellers        | c/o Siemens Nixdorf Informationssysteme AG  |
  58. |  USA: mollers.pad@sni-usa.com    | Abt. STO-XS 113       | Riemekestrasse   |
  59. | !USA: mollers.pad@sni.de    | Phone: (+49) 5251 835124 | D-4790 Paderborn |
  60.