home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0081.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  3.3 KB  |  62 lines
  1. Submitted-by: joost@ori.cadlab.de (Michael Joosten)
  2.  
  3. In article <sd58rINNbb@ftp.UU.NET>, berry@socrates.umd.edu (Joseph Berry) 
  4. writes:
  5. >>I am considering using the SUN light-weight process package (a threads library)
  6. >>for some software development. I would like to know if there are
  7. >>any standards for a threads library, so that the software can be fairly
  8. >>portable. Do SVR4 or OSF offer a threads library?
  9. >OSF offers a threads library. Furthermore, there is a pthreads "standard"
  10. >(not yet approved) POSIX 1003.4a.
  11.  
  12. The situation concerning threads libraries is currently a bit difficult. 
  13. Yes, OSF has POSIX pthread implementation in its DCE package. But it is
  14. unclear how to get only OSF pthreads (which are in reality DEC's CMA (Concert
  15. Multithread Architecture) threads) without all the DCE stuff around. For an
  16. educational site it was rather cheap to join OSF an buy a DCE snapshot (200$ +
  17. 1000$), I don't know what they charge now. 
  18.  
  19. Actually , SunSoft has apparently own plans on improving LWP. There is a paper
  20. about this in a recent USENIX (Winter '91 ?) about Sun's further development
  21. plus an interesting paper about how to take care of non-reentrant libraries.
  22.  
  23. USL? I don't kow, but I would like to hear a bit more about their intentions.
  24. Probably there is something emerging, especially with Chorus and the
  25. much-awaited MultiProcessing Release of SysVR4.
  26.  
  27. Since currently no vendor actually sells his Unix with a standardized pthreads
  28. AND re-rentrant libraries (except OSF with OSF/1, but that's not a vendor),
  29. the situation is actually a bit hosed: Many developers will face the task to
  30. convert their existing/emerging multithreaded programs to pthreads, and this
  31. could be not always easy. LWP, e.g., offers a yield() function which takes an
  32. explicit LWP argument, thus leading developers to play scheduler-by-their-own
  33. instead of relying on a built-in scheduler or sempahores/mutexes/condition
  34. variables/messages. This nearly happened here, and pthread has of course no
  35. such yield_to(xxx). An explicit yield_to() is fine for coroutines, but does
  36. not make sense for real threads where the scheduler has more kowledge about
  37. which (system) resource is blocked or ready (file descriptors,..) than the
  38. programmer.
  39.  
  40. Anyway, without re-entrant libs (libc_r.a) there is IMHO not so much profit
  41. with pthreads, since a premptive context change is mostly simulated with
  42. SIGALRM and the finer-grained BSD timer functions. Since most libraries are
  43. not built to cope with changing threads, you either must set 'guards' like
  44. mutexes around a lot of (if not all) C library functions (most of the section
  45. (3) stuff) or be extremly cautiously when coding your system. In the former
  46. case, you will likely lose performance; imagine your program oftenly call libc
  47. functions - every time the mutex has to be locked and released, maybe with an
  48. additional set/reset of the signal mask (expensive system call!).
  49.  
  50. Well, this is my perspective, now nearly 5-6 months old. If there's something
  51. radically changed, please let me know!
  52.  
  53. Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120
  54. CADLAB            |       Fax   : (+49) (+) 5251-284 140
  55. Bahnhofstr. 32    |       E-Mail: joost@cadlab.de
  56. D-4790 Paderborn  |                ...!uunet!unido!cadlab!joost
  57. FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de
  58.  
  59.  
  60. Volume-Number: Volume 27, Number 80
  61.  
  62.