
Signature
Doug Harrison
Microsoft MVP - Visual C++
> Yes. I said "almost" deterministically because it's using Sleep to fake out
> the scheduler, a practice that isn't guaranteed to work but does well
[quoted text clipped - 3 lines]
> example illustrated the use of foreground threads. Had you used background
> threads, or if you were to set the IsBackground property on the threads,
... the only way that I know for creating .NET background threads. Is
there another?
> your program would have terminated right away, because extant background
> threads don't keep a program alive once the primary thread has exited.
Yes indeed.
> Only
> foreground threads do that. In general, you should join with your secondary
> threads before exiting your primary thread.
You mean to join the primary thread and secondary threads all together?
However this doesn't sound much multithreading. :-)
Something else based on this, is it better to join dependent threads -
whenever possible- instead of using locks? What would this mean for
performance in multi-cpu/core environments? Is this a way to avoid the
thread lock mess, while sacrificing almost no speed?
Doug Harrison [MVP] - 26 Mar 2005 18:04 GMT
> ... the only way that I know for creating .NET background threads. Is
> there another?
Thread pool and by extension asynchronous delegates. In addition, unmanaged
threads that call into managed code are marked as background threads.
> You mean to join the primary thread and secondary threads all together?
> However this doesn't sound much multithreading. :-)
But if your program is shutting down, it's usually undesirable to allow
your secondary threads to continue to run as the larger environment in
which they're executiing is going away. To conduct an orderly shutdown,
your primary thread has to ask all your secondary threads to exit and join
with them first.
> Something else based on this, is it better to join dependent threads -
> whenever possible- instead of using locks?
Not sure what you mean. By "join" I mean wait for the thread to exit.
> What would this mean for
> performance in multi-cpu/core environments? Is this a way to avoid the
> thread lock mess, while sacrificing almost no speed?
Google on "lock-free programming". It's a hot topic these days.

Signature
Doug Harrison
Microsoft MVP - Visual C++
Carl Daniel [VC++ MVP] - 26 Mar 2005 22:12 GMT
>> Something else based on this, is it better to join dependent threads
>> - whenever possible- instead of using locks?
>
> Not sure what you mean. By "join" I mean wait for the thread to exit.
To the OP:
join is not rendezvous (in the Ada sense). You can only join a thread when
it terminates (the pattern and terminology comes from Java most directly,
but dates to long before Java was born).
-cd