🚀 go-pugleaf

Submitted-by: joost@ori.cadlab.de (Michael Joosten)

In article <sd58rINNbb@ftp.UU.NET>, berry@socrates.umd.edu (Joseph Berry) 
writes:
>>I am considering using the SUN light-weight process package (a threads library)
>>for some software development. I would like to know if there are
>>any standards for a threads library, so that the software can be fairly
>>portable. Do SVR4 or OSF offer a threads library?
>OSF offers a threads library. Furthermore, there is a pthreads "standard"
>(not yet approved) POSIX 1003.4a.

The situation concerning threads libraries is currently a bit difficult. 
Yes, OSF has POSIX pthread implementation in its DCE package. But it is
unclear how to get only OSF pthreads (which are in reality DEC's CMA (Concert
Multithread Architecture) threads) without all the DCE stuff around. For an
educational site it was rather cheap to join OSF an buy a DCE snapshot (200$ +
1000$), I don't know what they charge now. 

Actually , SunSoft has apparently own plans on improving LWP. There is a paper
about this in a recent USENIX (Winter '91 ?) about Sun's further development
plus an interesting paper about how to take care of non-reentrant libraries.

USL? I don't kow, but I would like to hear a bit more about their intentions.
Probably there is something emerging, especially with Chorus and the
much-awaited MultiProcessing Release of SysVR4.

Since currently no vendor actually sells his Unix with a standardized pthreads
AND re-rentrant libraries (except OSF with OSF/1, but that's not a vendor),
the situation is actually a bit hosed: Many developers will face the task to
convert their existing/emerging multithreaded programs to pthreads, and this
could be not always easy. LWP, e.g., offers a yield() function which takes an
explicit LWP argument, thus leading developers to play scheduler-by-their-own
instead of relying on a built-in scheduler or sempahores/mutexes/condition
variables/messages. This nearly happened here, and pthread has of course no
such yield_to(xxx). An explicit yield_to() is fine for coroutines, but does
not make sense for real threads where the scheduler has more kowledge about
which (system) resource is blocked or ready (file descriptors,..) than the
programmer.

Anyway, without re-entrant libs (libc_r.a) there is IMHO not so much profit
with pthreads, since a premptive context change is mostly simulated with
SIGALRM and the finer-grained BSD timer functions. Since most libraries are
not built to cope with changing threads, you either must set 'guards' like
mutexes around a lot of (if not all) C library functions (most of the section
(3) stuff) or be extremly cautiously when coding your system. In the former
case, you will likely lose performance; imagine your program oftenly call libc
functions - every time the mutex has to be locked and released, maybe with an
additional set/reset of the signal mask (expensive system call!).

Well, this is my perspective, now nearly 5-6 months old. If there's something
radically changed, please let me know!

Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120
CADLAB            |       Fax   : (+49) (+) 5251-284 140
Bahnhofstr. 32    |       E-Mail: joost@cadlab.de
D-4790 Paderborn  |        	    ...!uunet!unido!cadlab!joost
FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de


Volume-Number: Volume 27, Number 80