RE: DEC Threads

[johill@lanl.gov (Jeff Hill)]

Hello,

It would greatly simplify my job if I could count on the 
availability of threads on all OS that we use. At this
point VMS is the only system with unresolved questions.

I understand that in VMS systems today all access to sockets,
whether Multinet is installed or not, goes through the DEC
socket library. I have been poking around in the VMS doc on the 
web and I am not certain that the DEC socket library is thread 
safe. It appears that it is not safe to call a socket routine
from an AST, but this is really not the same thing as calling
from two threads. I have similar worries about the ANSI C library 
and other fundamental interfaces. If threads are an option then 
I also need to know what OS and layered package versions must be 
used prior to asking about the impact of this on the mail list. 
Do any of you know a VMS GURU who (perhaps yourself) that can 
answer these questions, or perhaps someone could call tech support
at DEC (now COMPAQ) or at multinet's TGV (now CISCO).

Jeff

> -----Original Message-----
> From: J. Frederick Bartlett (bartlett@fnal.fnal.gov)
> [mailto:bartlett@d0mino.fnal.gov]
> Sent: Wednesday, December 01, 1999 2:52 PM
> To: Jeff Hill
> Cc: EPICS-tech-talk; bartlett@d0mino.fnal.gov
> Subject: Re: DEC Threads 
> 
> 
> Jeff,
> 
>   Yes, DEC threads is a real thread-supporting package with a rich
> assortment of synchronization mechanisms. The early version of this,
> which is probably what your documentation describes, was a prototype
> for what became POSIX threads (POSIX.4A) or pthreads. Unfortunately,
> The DEC threads package was superior, in many ways, to pthreads. Your
> document should also describe the early version of pthreads as well.
> 
>   Most platforms provide an implementation of pthreads and that,
> probably, is the best choice of a threading package if you want
> maximum portability. Depending upon the implementation, the threads
> may not be known to the OS (user-space), known to the OS kernel
> (kernel-space), or somewhere in between. One of the deficiencies of
> pthreads is that it does not offer a recursive mutex; so, if the same
> thread tries to lock a mutex more than once, as might occur when
> library packages are used, the thread becomes permanently blocked. It
> is possible, however, to create a recursive lock using the pthreads
> routines.
> 
>   An alternative to pthreads is ACE that, although it is principally a
> high-level message-passing package, has thread support included.  It
> works on many platforms although the installation is not trivial and
> the size is daunting.  It is probably possible to remove the thread
> support and use it without all of the other, memory overhead. As I
> recall, ACE uses pthreads on many of the supported platforms.
>  
>   For an introduction to the topic, you might start with one of the
> O'Reilly & Associates books, "Pthreads Programming", by Nichols,
> Buttlar, and Farrell. A superior book is "Programming with Threads" by
> Kleiman, Shah, and Smaalders published by Prentice-Hall.
> 
> 						Fritz
> 
>