Conference clt::cma

.0> Why is there a tis_cond_wait but no tis_cond_timedwait?

A better question might be, "why is there a condition wait function when it
cannot possibly be signalled (in the absence of other threads)?"  

The answer is that there was a good case for libraries needing it for the case
when there -were- other threads, and it was easy to define for the case when
there -weren't- other threads (it aborts the process!).

However, for timed-wait, we haven't been presented with a justification strong
enough to make us figure out what it should do when no other threads are
present.  (I.e., I fear that this function is a can of worms that we don't want
to open, and I haven't seen a good enough reason to open it, yet.)

.0> How strictly enforced is this "intention" from <tis.h>?

The idea is that if your code wants to use threads, then there is no reason to
use the TIS interface instead of the pthread one, since you already use the
pthread interface to -create- the threads, and since the TIS interface is very
slightly higher overhead than the pthread interface when threads are present; if
your code does not want to create threads, then you would probably prefer to use
the TIS one, since it doesn't force the rest of the threads environment and
accompanying overhead to be pulled in.  So, we don't enforce this "intention"...
what interface you use is up to you.

.0> Does it ever make sense to mix tis and pthread at all?

Um...  I think I'll stick with "no".

When you say "mix", I presume you are talking about in the same product, or
possibly in the same module.  I hope it's obvious that there's no reason why a
product which uses threads cannot use a library which uses TIS....

.0> Is it correct that routines such as localtime and strtok use
.0> thread-local static data on VMS and NT but not on Digital Unix ?

You'd have to get the answer from the C RTL folks on the various platforms.  (I
believe that localtime() is implemented with thread-local (dynamic) storage on
all the platforms; I've no idea how strtok() came out....)


				Webb

> .0> Is it correct that routines such as localtime and strtok use
> .0> thread-local static data on VMS and NT but not on Digital Unix ?
> You'd have to get the answer from the C RTL folks on the various platforms.  (I
> believe that localtime() is implemented with thread-local (dynamic) storage on
> all the platforms; I've no idea how strtok() came out....)

	I also believe you'd have to ask for specific versions of the OS,
	at least with Digital UNIX.  I don't believe the rtl supported
	TLS until V4.  Prior to that you had to use the _r version of
	local time if you were using threads.

The tis_cond_timedwait() function has already been added. I don't remember
why, but someone wanted it badly enough to convince someone that we should
include it. Without threads, it just calls sleep() [UNIX] or lib$wait [VMS]
and returns with ETIMEDOUT. (There's no way for the condition variable to be
signaled or broadcast without another thread, so it's just a timed wait.)
This TIS should ship with Digital UNIX 4.0D, and with some future version of
OpenVMS.

By the way, there's no such thing as "thread-local static". There are
compilers on some systems that know how to use our thread-specific data (or
equivalents in proprietary thread interfaces, such as Win32) to allow
compile-time declarations of "thread-local storage" (TLS) -- but there's
nothing "static" about it. It's just a slightly more transparent way for code
to declare & initialize thread-specific data.

Digital UNIX 4.0D will support TLS, and libc may use it for some functions.
OpenVMS does not have TLS, nor are there any current plans to add it.

	/dave

I understood the question to be this:

"I'm implementing a collection of functions.  Some of the functions may
be used with a single-thread process, so they would logically use TIS
operations.  Other functions only make sense if there are multiple threads
around, and do things that aren't available with TIS operations.  Is there
any problem with having some functions in my collection calling TIS, and
others calling PTHREAD operations?"

Does simply including PTHREAD calls cause something magic to happen at
startup time, such that the TIS calls do their heavyweight thing?  Or is
that deferred until the first PTHREAD_CREATE occurs?

I can't think of any technical reason why you couldn't use both TIS and
pthread interfaces -- it's just that there's no point.

You can include <pthread.h> without any "magic" -- in fact, <tis.h> always
includes <pthread.h> to get some definitions.

However, once you decide to write code that calls pthread_ functions, you
have to LINK against DECthreads. And when you activate an executable that's
linked against DECthreads, you've got a THREADED process -- even if it never
has any threads except the default thread. There's no reason to use TIS in a
threaded process, because it just calls DECthreads (adding minimal overhead
and no benefit).

	/dave

I had been under the impression that TIS switches over to using
threads at runtime when pthread_create is called, particularly
since I read some remarks about tis_self returning different
values before and after initialising threads.

If LINKING the executable with threads forces TIS to go through
all the pthread code anyway, then to get any benefit from TIS,
we have to move the few functions that call pthread_create and
tis_ sorry pthread_timed_condwait out of our shared library
and ask the customer to link with an extra object file as well
as the shared library when their application uses threads.

Phil

.6> So multi-threading is decided at linktime not at runtime

Well, actually, the decision _is_ made at run-time, when the DECthreads
library is loaded; however, the decision on whether to load that library is,
generally speaking, made at link-time....


				Webb

    Just to clarify -- the use or non-use of the pthread_create
    call has nothing to do with redirecting tis_ calls from libc
    to libpthread. If the threads library is there, you've got
    a multithreaded application, pthread_create or not. You've
    only got on *application* thread, but you have a number of
    other threads created by library initialization.
    
    FWIW.