Conference clt::cma

	Not with the DCE pthreads interface, and I doubt the now
	formal standard pthread interface does either.  I've seen
	propriatary interfaces that allow you you to wait (join)
	with any thread, but that's not portable functionality.

	The portable (and only way w/pthreads) to do what you want is to
	create a global (or pass handles to each of the two threads) flag
	and corresponding condition and mutex variables.  The
	worker threads should then lock the mutex, set the flag
	variable, unlock the mutex and then signal the condition
	variable (the last two operations can be done in any order).

	of course it might be easier if you simply have the worker
	thread call process exit ........

	pseudo example code:

int flag = 0;
pthread_mutex_t mutex;
pthread_mutex_t cond;

main()
	init(mutex)
	init(cond)

	createthread(worker)
	createthread(worker)

	lock(mutex)
	while( ! flag )
		condwait(cond, mutex)
	unlock(mutex)
	
	// note, do *not* destroy the mutex or cond variable here,
	// or you'll have a timing window where the other worker could
	// finish and try to lock/signal right after you've destroyed
	// them, but before the process exits.
	exit()

worker()
	dowork()
	lock(mutex)
	flag++;
	unlock(mutex)
	signal(cond)
	exitthread()

Threads CANNOT have a "wait for any thread" equivalent to the UNIX "wait for
any process". Although some systems provide it, it's very dangerous. The
reason is that processes have parent/child relationships, and you can only
wait for (all of) YOUR children.

Threads are all equals -- so "wait for any" would wait for ANY thread, not
just the threads you'd created. Your "pthread_join_any" might, for example,
reap a thread created by a sorting or database runtime -- you might not even
be aware that such a package is in use, much less that it create threads.
You've now "stolen" a return status that means nothing to you, and the
package's pthread_join will then fail because the thread no longer exists.

In any case, pthread_join is nothing but a trivial helper function for the
most common case. You don't need it. As Bill demonstrated, making your own
"join" is easy. You can build a join that will return when any of some set of
threads exits, when some number of them exit, or whatever you want.

	/dave

Just to complete Dave's explanation in .2, there obviously is a middle ground
between "join with this (one) thread" and "join with any (unspecified) thread",
namlye "join with any of the following specific threads".  But the problem is
that the interface is tricky to specify in a reasonable manner, the
implmentation is cumbersome at best, and the final result is unlikely to do what
you want it to do in every case.

So, since it's so straightforward for you to roll your own, and it will do
exactly what you want, we decided it was best not to try to provide this
particular piece of meta-functionality.


				Webb

    The reason we wanted this is for portability with NT.  NT has
    WaitForMultipleObjects which allows you to specify thread handles, when
    any of the threads exit the wait exits.  I will roll my own.
    
    Dan
    

> The reason we wanted this is for portability with NT.  NT has
> WaitForMultipleObjects which allows you to specify thread handles, when
> any of the threads exit the wait exits.

	NT had the benifit of coming last and being able to learn from
	the past.  Almost everything in NT is a real object and can
	be waited for all at once (threads, processes, file handles, event
	objects, semaphores, mutexes, etc, but not lightweight mutexes,
	ala CRITICAL_SECTION).

    > NT had the benifit of coming last and being able to learn from the
    > past.  Almost everything in NT is a real object and can be waited for
    > all at once (threads, processes, file handles, event objects,
    > semaphores, mutexes, etc, but not lightweight mutexes, ala
    > CRITICAL_SECTION).
      
    And VAXELN had it first! Oh, yeah, same as NT....