By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,458 Members | 1,280 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,458 IT Pros & Developers. It's quick & easy.

Joining threads; why?

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Eric Sabine" <mopar41@mail_after_hot_not_before.com> wrote in message
news:eX**************@tk2msftngp13.phx.gbl...
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

Nov 16 '05 #2

P: n/a
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.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"Eric Sabine" <mopar41@mail_after_hot_not_before.com> schrieb im Newsbeitrag
news:eX**************@tk2msftngp13.phx.gbl...
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

Nov 16 '05 #3

P: n/a
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?

Nicholas Paldino [.NET/C# MVP] wrote:
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.

"Eric Sabine" <mopar41@mail_after_hot_not_before.com> wrote in message
news:eX**************@tk2msftngp13.phx.gbl...
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

Nov 16 '05 #4

P: n/a
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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Eric Sabine" <mopar41@mail_after_hot_not_before.com> wrote in message
news:OJ**************@TK2MSFTNGP11.phx.gbl...
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?

Nicholas Paldino [.NET/C# MVP] wrote:
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.

"Eric Sabine" <mopar41@mail_after_hot_not_before.com> wrote in message
news:eX**************@tk2msftngp13.phx.gbl...
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


Nov 16 '05 #5

P: n/a
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/<eU**************@TK2MSFTNGP11.phx.gbl>

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.

--
cody
Nov 16 '05 #6

P: n/a

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

"Eric Sabine" wrote:
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

Nov 16 '05 #7

P: n/a
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

"Eric Sabine" <mopar41@mail_after_hot_not_before.com> wrote in message
news:eX**************@tk2msftngp13.phx.gbl...
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

Nov 16 '05 #8

P: n/a
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.

"Eric Sabine" wrote:
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

Nov 16 '05 #9

P: n/a
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.

"Eric Sabine" wrote:
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

Nov 16 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.