Joining threads; why?

  • Thread starter Thread starter cody
  • Start date Start date
C

cody

Joining a thread, practically means ending/closing the thread, and normally
a thread joins threads which they started by theirselves, although you can
do it the other way around but most times it doesn't make sense to do so.
 
Can someone give me a practical example of why I would join threads? I am
assuming that you would typically join a background thread with the UI
thread and not a background to a background, but since I'm asking in the
first place, assume that assumption to be very assuming.

thanks,
Eric
 
Eric,

It depends on what you are trying to do. One example I can think of
would be when you have two unrelated sets of data which you need to process.
You have to process both of them, and then perform a third process. The
first and the second are unrelated, but the third can't be executed until
the first two are processed.

As a really simple example, let's say you have two proprietary
structured files, which you want to join into a data set and for some
reason. You could parse one file on one thread, and another on another
thread. You would then wait until they were both parsed to add them into
the data set. In that case, you would join on the other threads doing the
work, waiting for them to complete so you could proceed with the merge.

Hope this helps.
 
OK those seem like two good examples of joining background threads. Thanks.
What about joining a worker with the UI thread. Do you ever do that?
 
Eric,

You don't want to do that. The reason is that the call to Join will
block on the UI thread, and it will freeze. If anything, make the call to
Join on another thread, and then when that call returns, send a notification
to the UI thread to perform whatever updating it needs to do.

Hope this helps.
 
A small nit. Joining doesn't end or close the thread - it is a wait operation similar to WaitForSingleObject(threadHandle, timeout); So it waits for the thread to end.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

Joining a thread, practically means ending/closing the thread, and normally
a thread joins threads which they started by theirselves, although you can
do it the other way around but most times it doesn't make sense to do so.
 
Here's another real world join example:

I have a windows service. The service spins off two worker threads - one
thread processes file input the other thread processes Tcp socket based
input. Both threads in turn spin off many many thread pool threads to do
socket & SQL Server work. The thread pool threads do tasks that range from a
few hundred milliseconds to a few seconds and they synchronize with my two
main worker threads; aka my two main worker threads no if/how many thread
pool threads are active.

In order to get a 'clean' shutdown of my service - with no orphaned files or
half closed sockets or aborted database transactions - I need to wait for all
of the thread pool threads to finish, then wait for both of my worker threads
to finish.

Sooo, code in my service signals a stop/shutdown event and then it joins on
the two worker threads. The two worker threads wait for thread pool threads
to finish and then they stop. Once the worker threads have stopped it is
safe to unload the service from memory...

--Richard
 
Theoretical problems are always interesting, if not practical.

In a multithreaded system, you can easily imagine situations where you have
split up processing on multiple threads, yet the answer requires all of the
threads to come together.

This is especially true if there is an external resource that you need to
access.

For example: you need to get data from a web site, and data from an excel
spreadsheet, and data from a sql server database, pull them all together,
perform some calculations, and present the results in a User interface.

Sure, you could create one background thread to do things in a serial
fashion, but why not create three threads: one to attach to SQL, one to open
the spreadsheet, and one to access the web site. Each of these can have
aspects that could delay processing. The network could be down or slow...
SQL could be offline... the spreadsheet data may require you to load Excel
into memory, which simply takes up resources.

I promise one thing: they won't all finish at the same time. However, your
calculations, still a background operation, requires all three datasets. So
you join threads and do not proceed until all three have delivered data.
Then you complete the calculation, set the data where the U/I can find it,
and trigger the U/I.

HTH

--- Nick
 
Hi

An example is that a background thread connects to a FTP site, copies the
content of a file after some processing to a locally created new file.
Another thread queries a database and after some processing adds the result
to that file. In this scenario we took advantage of concurrency but task 2
needs to write to file after task 1 is finished but it can start querying
right away so we join thread 2 to thrad 1 before writing to the file by
thread 2.
 
Hi

An example is that a background thread connects to a FTP site, copies the
content of a file after some processing to a locally created new file.
Another thread queries a database and after some processing adds the result
to that file. In this senarion we took advantage of concurrency but task 2
needs to be done after task 1 is finished so we join thread 2 to thrad 1.
 
Back
Top