home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / research / 872 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  1.8 KB
  1. Path: sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!osr
  2. From: Jack_Palevich@taligent.com (Jack Palevich)
  3. Newsgroups: comp.os.research
  4. Subject: Re: Lightweight threads and "real" users
  5. Message-ID: <17n06qINN793@darkstar.UCSC.EDU>
  6. Date: 29 Aug 92 04:59:06 GMT
  7. References: <13cn3eINN8cn@darkstar.UCSC.EDU> <13sb8pINNn28@darkstar.UCSC.EDU>
  8. Organization: Taligent, Inc.
  9. Lines: 31
  10. Approved: comp-os-research@ftp.cse.ucsc.edu
  11. NNTP-Posting-Host: ftp.cse.ucsc.edu
  12. Originator: osr@ftp
  13.  
  14. The best practical advice I've seen on using lightweight threads is the DEC
  15. SRC report "An Introduction to Programming with Threads", by Andrew D.
  16. Birrell. (35 pages. (C) 1989 Digital Equipment Corp. Systems Research
  17. Center, Palo Alto, CA. I believe that the SRC will mail you a paper copy of
  18. this report on request, but I don't know their full address.)
  19.  
  20. The DEC SRC report seems to have been influenced by earlier Xerox PARC work
  21. on the Mesa language. Mesa had language support for threads, monitors and
  22. conditions.
  23.  
  24. Several years ago, when I started to program concurrently, a wise veteran
  25. gave me this advice:
  26.  
  27. 1) Within an address space use monitors & conditions, rather than raw
  28. semaphores.
  29.  
  30. 2) Never call out of your scope with a monitor held.
  31.  
  32. 3) Between address spaces use synchronous send-and-wait-for-reply
  33. messaging, rather than asynch messaging.
  34.  
  35. -- Of course, because I was young and full of beans, I ignored his advice. 
  36. I said, "But why must I do this?  Can't I bend these rules just a little
  37. bit? Surely one additional little feature won't get me in trouble!"
  38.  
  39. The veteran just smiled sadly.
  40.  
  41. Now, several years later, I have come to believe in these rules
  42. whole-heartedly. If you follow them, then you should have no problems using
  43. concurrency. If you don't, you'll gain a deeper understanding of the
  44. complexity of concurrent programming. :-)
  45.