Hi,
How do I wait until a thread is finished his job then continue to the
original thread?
public void main(string[] args)
{
Thread t = new Thread(new ThreadStart(DoWork));
t.Start();
while(t.IsAlive)
{
// I don't know how to wait until thread t is done
// then execute MessageBox below. I don't want
// a blank while loop body because it takes up 100%
// of my CPU
}
MessageBox.Show("Bla");
}
private void DoWork()
{
// do more
}
Please advice, thanks!
-P
13  2038 
t.Start();
t.Join();
// Go on ....
Willy.
"Paul" <Pa**@discussions.microsoft.com> wrote in message
news:32**********************************@microsof t.com... Hi,
How do I wait until a thread is finished his job then continue to the
original thread?
public void main(string[] args)
{
Thread t = new Thread(new ThreadStart(DoWork));
t.Start();
while(t.IsAlive)
{
// I don't know how to wait until thread t is done
// then execute MessageBox below. I don't want
// a blank while loop body because it takes up 100%
// of my CPU
}
MessageBox.Show("Bla");
}
private void DoWork()
{
// do more
}
Please advice, thanks!
-P
Willy Denoyette [MVP] <wi*************@pandora.be> wrote: t.Start();
t.Join();
// Go on ....
And then you need to ask yourself why you want another thread in the
first place. If you're going to start a thread and then block the
current thread until the new thread has finished, why not just call the
method directly in the original thread?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon,
I don't have to ask myself, OP should ask :-).
I see many people experimenting with threads these day's, probably to learn
how they work and hopefuly to discover that there is a lot that can be done
without them.
Maybe a better answer would have been...
t.Start();
// if you have something to run in parallel, do it now, else don't use a
thread and call your procedure here.
// finally, If you need the outcome of the thread procedure or you simply
want to be sure the thread procedure finished it's job
// call:
t.Join();
Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Willy Denoyette [MVP] <wi*************@pandora.be> wrote: t.Start();
t.Join();
// Go on ....
And then you need to ask yourself why you want another thread in the
first place. If you're going to start a thread and then block the
current thread until the new thread has finished, why not just call the
method directly in the original thread?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Another reason to call t.Join() instead of an other "blocking wait" is to
pump messages while waiting for your thread to finish.
Willy.
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:eo**************@TK2MSFTNGP11.phx.gbl... Jon,
I don't have to ask myself, OP should ask :-).
I see many people experimenting with threads these day's, probably to
learn how they work and hopefuly to discover that there is a lot that can
be done without them.
Maybe a better answer would have been...
t.Start();
// if you have something to run in parallel, do it now, else don't use a
thread and call your procedure here.
// finally, If you need the outcome of the thread procedure or you simply
want to be sure the thread procedure finished it's job
// call:
t.Join();
Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Willy Denoyette [MVP] <wi*************@pandora.be> wrote: t.Start();
t.Join();
// Go on ....
And then you need to ask yourself why you want another thread in the
first place. If you're going to start a thread and then block the
current thread until the new thread has finished, why not just call the
method directly in the original thread?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Willy,
You are not suggesting that if you block the UI thread in Join() the message
pump will keep runing, are you?
--
Stoitcho Goutsev (100) [C# MVP]
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uc**************@TK2MSFTNGP15.phx.gbl... Another reason to call t.Join() instead of an other "blocking wait" is to
pump messages while waiting for your thread to finish.
Willy.
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:eo**************@TK2MSFTNGP11.phx.gbl... Jon,
I don't have to ask myself, OP should ask :-).
I see many people experimenting with threads these day's, probably to
learn how they work and hopefuly to discover that there is a lot that can
be done without them.
Maybe a better answer would have been...
t.Start();
// if you have something to run in parallel, do it now, else don't use a
thread and call your procedure here.
// finally, If you need the outcome of the thread procedure or you simply
want to be sure the thread procedure finished it's job
// call:
t.Join();
Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Willy Denoyette [MVP] <wi*************@pandora.be> wrote:
t.Start();
t.Join();
// Go on ....
And then you need to ask yourself why you want another thread in the
first place. If you're going to start a thread and then block the
current thread until the new thread has finished, why not just call the
method directly in the original thread?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Wil,
I actually run this in my win form. So the complete scenario is that I have
a datagrid and I want to run FillDG() in different thread and once it
finishes, I want to bind the data.
private void button1_Click(object sender, System.EventArgs e)
{
Thread t = new Thread(new ThreadStart(FillDG));
t.Start();
// I need to wait for t to finish
// I tried t.Join(); but this locked up the win form, i.e. I can't move the
form around
myDataGrid.SetDataBinding(myDataSet, "myDataTable");
}
Any idea how?
-P
"Willy Denoyette [MVP]" wrote: Jon,
I don't have to ask myself, OP should ask :-).
I see many people experimenting with threads these day's, probably to learn
how they work and hopefuly to discover that there is a lot that can be done
without them.
Maybe a better answer would have been...
t.Start();
// if you have something to run in parallel, do it now, else don't use a
thread and call your procedure here.
// finally, If you need the outcome of the thread procedure or you simply
want to be sure the thread procedure finished it's job
// call:
t.Join();
Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Willy Denoyette [MVP] <wi*************@pandora.be> wrote: t.Start();
t.Join();
// Go on ....
And then you need to ask yourself why you want another thread in the
first place. If you're going to start a thread and then block the
current thread until the new thread has finished, why not just call the
method directly in the original thread?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Because it will lock my windows form, i.e. I can't move the form around.
-P
"Jon Skeet [C# MVP]" wrote: Willy Denoyette [MVP] <wi*************@pandora.be> wrote: t.Start();
t.Join();
// Go on ....
And then you need to ask yourself why you want another thread in the
first place. If you're going to start a thread and then block the
current thread until the new thread has finished, why not just call the
method directly in the original thread?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Paul <Pa**@discussions.microsoft.com> wrote: Because it will lock my windows form, i.e. I can't move the form around.
Then you don't want to call Join, either. You want to let your UI
thread method return, so the UI thread can keep running the message
pump, and get your other thread to use Control.Invoke/BeginInvoke to
let the UI know when it's finished, so it can take relevant action.
See http://www.pobox.com/~skeet/csharp/t...winforms.shtml
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Stoitcho,
Yes, the CLR will perform a limited amount of pumping when in a
Thread.Join(), the same applies for GC.WaitForPendingFinalizers(1) and some
other managed wait API's like WaitHandle.WaitOne (2). One of the reasons for
this is to prevent the finalizer thread to block when attempting
inter-thread marshaling between the Finalizer thread (MTA) and an STA
thread, in a scenario that the Finalizer needs to Release a COM object
(calling IUnknown::Release on the RCW) that lives in the STA.
Note that UI threads, also running in an STA, don't need this as there is a
lot of pumping going on, but non UI threads running in an STA better pump
messages when hosting COM objects in finalizable objects. Failing to pump
results in a stalled finalizer, a growing number of unreleased COM
references (and resources, like unmanaged memory) and finally a process
crash.
1) Note that GC.WaitForPendingFinalizers also waits for the finalizer queue
to drain.
2) That's one of the reasons not to use the OS synchronization primitives in
managed code.
Willy.
"Stoitcho Goutsev (100) [C# MVP]" <10*@100.com> wrote in message
news:eY**************@TK2MSFTNGP09.phx.gbl... Willy,
You are not suggesting that if you block the UI thread in Join() the
message pump will keep runing, are you?
--
Stoitcho Goutsev (100) [C# MVP]
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uc**************@TK2MSFTNGP15.phx.gbl... Another reason to call t.Join() instead of an other "blocking wait" is to
pump messages while waiting for your thread to finish.
Willy.
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:eo**************@TK2MSFTNGP11.phx.gbl... Jon,
I don't have to ask myself, OP should ask :-).
I see many people experimenting with threads these day's, probably to
learn how they work and hopefuly to discover that there is a lot that
can be done without them.
Maybe a better answer would have been...
t.Start();
// if you have something to run in parallel, do it now, else don't use a
thread and call your procedure here.
// finally, If you need the outcome of the thread procedure or you
simply want to be sure the thread procedure finished it's job
// call:
t.Join();
Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@pandora.be> wrote:
> t.Start();
> t.Join();
> // Go on ....
And then you need to ask yourself why you want another thread in the
first place. If you're going to start a thread and then block the
current thread until the new thread has finished, why not just call the
method directly in the original thread?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Willy,
Where did you get that information. I doesn't make any sense to me. If you
have any sources (links, books, articles, etc) I'll appreciate if you post
them here.
See my opinion inlined Yes, the CLR will perform a limited amount of pumping when in a
CLR cannot perform any pumping simply because the pumping has to be done by
the UI thread itself. It is blocked to perform pumping means that the thread
needs to be unblocked and let executing the code. That is exactly what the
programmer called Join wants to avoid. What if the execution loops back and
executes the same lines of code thus, instantiate and start new thread and
call new Join. If this is possible why one would block the main thread one
simply can let the main thread go.
Once the thread is blocked that's it it is blocked, period.
Thread.Join(), the same applies for GC.WaitForPendingFinalizers(1) and
some other managed wait API's like WaitHandle.WaitOne
(2). One of the reasons for this is to prevent the finalizer thread to block when attempting
inter-thread marshaling between the Finalizer thread (MTA) and an STA
thread, in a scenario that the Finalizer needs to Release a COM object
(calling IUnknown::Release on the RCW) that lives in the STA.
Indeed. That exactly what happens. The finalizer thread blocks as well as
the thread calling WaitForPandingFinalizers. Deadlock!?! Well, not exactly
because CLR gives certain amount of time for all finalizers to finish. If
some of the finalizers are not executed... well, too bad for them.
There is KB article addressing this issue:
http://support.microsoft.com/default...b;en-us;828988
Note that UI threads, also running in an STA, don't need this as there is
a lot of pumping going on, but non UI threads running in an STA better
pump messages when hosting COM objects in finalizable objects.
Non-UI thread doesn't pump because they don't have message queue. That's why
they are called non-UI.
Further more non-UI STA threads cannot host (create) COM objects simply
because STA apartment marshal's via windows messages thus, the thread has to
have message queue (UI thread)
Failing to pump results in a stalled finalizer, a growing number of
unreleased COM references (and resources, like unmanaged memory) and
finally a process crash.
Exactly. That's exactly what happens. That's why if creating COM objects in
STA thread and the object has finalizer that calls Release, don't call
WaitForPandingFinalizers
1) Note that GC.WaitForPendingFinalizers also waits for the finalizer
queue to drain.
Not exactly threre is a timeout.
2) That's one of the reasons not to use the OS synchronization primitives
in managed code.
Well. .NET has enough sync primitives (each of which I believe are based on
OS primitives at the moment)
The bottom line: When the thread is blocked that's it it is blocked, period.
There is no semiblocked threads.
While GC.WaitFor.... and COM object is not easily to verify (fortunately
there is KB article for that) all other sync methods can be tested. Just run
some tests and you'll see there is no pumping.
--
Stoitcho Goutsev (100) [C# MVP]
Hi Stoitcho,
I don't want to start a long discussion on this complicated subject before
you did read the sources[1], I'm not sure this can even be discussed in
great detail in a public forum without me breaking some NDA.
See inline ****
Willy.
"Stoitcho Goutsev (100) [C# MVP]" <10*@100.com> wrote in message
news:O2**************@TK2MSFTNGP15.phx.gbl... Hi Willy,
Where did you get that information. I doesn't make any sense to me. If you
have any sources (links, books, articles, etc) I'll appreciate if you post
them here.
****
[1] Here are the links, most notably chris brummes blogs will be enlightning
:-)
http://blogs.msdn.com/cbrumme/archiv.../20/77460.aspx
http://blogs.msdn.com/cbrumme/archiv.../20/77460.aspx
http://blogs.msdn.com/maoni/archive/...04/252697.aspx
Another great source of info are the VM source files, I have access to the
MSFT .NET sources (no, not Rotor) files through the Code Center Premium
license.
and : http://support.microsoft.com/default...b;en-us;828988
See my opinion inlined
Yes, the CLR will perform a limited amount of pumping when in a
CLR cannot perform any pumping simply because the pumping has to be done
by the UI thread itself. It is blocked to perform pumping means that the
thread needs to be unblocked and let executing the code. That is exactly
what the programmer called Join wants to avoid. What if the execution
loops back and executes the same lines of code thus, instantiate and start
new thread and call new Join. If this is possible why one would block the
main thread one simply can let the main thread go.
Once the thread is blocked that's it it is blocked, period.
**** Beware the difference between a logical (CLR) and a physical
(OS)thread. The CLR hijacks the UI thread (OS) when calling Join(), this is
not the same as blocking a thread at the OS level. (Note: UI thread here
means a thread with a HWND associated, not necessarily a visible windows)
Thread.Join(), the same applies for GC.WaitForPendingFinalizers(1) and
some other managed wait API's like WaitHandle.WaitOne
(2). One of the reasons for this is to prevent the finalizer thread to block when attempting
inter-thread marshaling between the Finalizer thread (MTA) and an STA
thread, in a scenario that the Finalizer needs to Release a COM object
(calling IUnknown::Release on the RCW) that lives in the STA.
Indeed. That exactly what happens. The finalizer thread blocks as well as
the thread calling WaitForPandingFinalizers. Deadlock!?! Well, not exactly
because CLR gives certain amount of time for all finalizers to finish. If
some of the finalizers are not executed... well, too bad for them.
There is KB article addressing this issue:
http://support.microsoft.com/default...b;en-us;828988
**** Did you read the complete article, this is a snip taken from the bottom
of the page:
If you must use STA threads to create COM components, the STA threads must
pump messages regularly. To pump messages for a short time, call the
Thread.Join method, as follows:
Thread.CurrentThread.Join(100)This method call pumps messages for 100
milliseconds. You can adjust the time-out based on the requirements of the
application. Also, the STA thread should never perform unbounded non-pumping
operations, such as calling Console.ReadLine. Instead, the STA thread must
have a MTA thread perform the operation and then wait for the operation to
finish.
REFERENCES
Note that UI threads, also running in an STA, don't need this as there is
a lot of pumping going on, but non UI threads running in an STA better
pump messages when hosting COM objects in finalizable objects.
Non-UI thread doesn't pump because they don't have message queue. That's
why they are called non-UI.
Further more non-UI STA threads cannot host (create) COM objects simply
because STA apartment marshal's via windows messages thus, the thread has
to have message queue (UI thread)
*** Not exactly, OLE checks if the thread has a window handle associated
when entering an STA, if not OLE creates a hidden window and a message
queue. But, you have to pump messages of course. Remember: One of the rules
of COM mandates re-entrency for STA hosted objects.
Failing to pump results in a stalled finalizer, a growing number of
unreleased COM references (and resources, like unmanaged memory) and
finally a process crash.
Exactly. That's exactly what happens. That's why if creating COM objects
in STA thread and the object has finalizer that calls Release, don't call
WaitForPandingFinalizers
1) Note that GC.WaitForPendingFinalizers also waits for the finalizer
queue to drain.
Not exactly threre is a timeout.
Bad wording, it wait's a certain amount of time (that's changed in CLR v2).
2) That's one of the reasons not to use the OS synchronization primitives
in managed code.
Well. .NET has enough sync primitives (each of which I believe are based
on OS primitives at the moment)
Yes, but the OS primitives are wrapped by the CLR's synch. primitives. The
CLR is free to do anything he likes, you would be supprised to see what he's
doing before calling into the OS :-)
The bottom line: When the thread is blocked that's it it is blocked,
period. There is no semiblocked threads.
While GC.WaitFor.... and COM object is not easily to verify (fortunately
there is KB article for that) all other sync methods can be tested. Just
run some tests and you'll see there is no pumping.
Just run the native debugger, and see there is pumping :-)
--
Stoitcho Goutsev (100) [C# MVP]
Cool, thanks!
-P
"Jon Skeet [C# MVP]" wrote: Paul <Pa**@discussions.microsoft.com> wrote: Because it will lock my windows form, i.e. I can't move the form around.
Then you don't want to call Join, either. You want to let your UI
thread method return, so the UI thread can keep running the message
pump, and get your other thread to use Control.Invoke/BeginInvoke to
let the UI know when it's finished, so it can take relevant action.
See http://www.pobox.com/~skeet/csharp/t...winforms.shtml
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: adeger |
last post by:
Having trouble with my first forays into threads. Basically, the
threads don't seem to be working in parallel (or you might say are
blocking). I've boiled my problems to the following short code...
|
by: Gilles Leblanc |
last post by:
Hi I have started a small project with PyOpenGL. I am wondering what
are the options for a GUI. So far I checked PyUI but it has some
problems with 3d rendering outside the Windows platform.
I...
|
by: Ivan |
last post by:
Hi
I have following problem: I'm creating two threads who are performing some
tasks. When one thread finished I would like to restart her again (e.g. new
job). Following example demonstrates...
|
by: Matthew Groch |
last post by:
Hi all,
I've got a server that handles a relatively high number of concurrent
transactions (on the magnitude of 1000's per second). Client
applications establish socket connections with the...
|
by: Razzie |
last post by:
Hi all,
A question from someone on a website got me thinking about this, and I
wondered if anyone could explain this.
A System.Threading.Timer object is garbage collected if it has no...
|
by: droopytoon |
last post by:
Hi,
I start a new thread (previous one was "thread timing") because I have
isolated my problem.
It has nothing to do with calling unmanaged C++ code (I removed it in a
test application).
I...
|
by: mareal |
last post by:
I have noticed how the thread I created just stops running. I have added
several exceptions to the thread
System.Threading.SynchronizationLockException
System.Threading.ThreadAbortException...
|
by: Bob Day |
last post by:
Using vs2003, vb.net
I start a thread, giving it a name before start. Code snippet:
'give each thread a unique name (for later identification)
Trunk_Thread.Name = "Trunk_0_Thread"
' allow...
|
by: Charles Law |
last post by:
My first thought was to call
WorkerThread.Suspend
but the help cautions against this (for good reason) because the caller has
no control over where the thread actually stops, and it might have...
|
by: John Nagle |
last post by:
There's no way to set thread priorities within Python, is there?
We have some threads that go compute-bound, and would like to
reduce their priority slightly so the other operations, like...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
