thread

t.Start();
t.Join();
// Go on ....

Willy.

"Paul" <Pa**@discussio ns.microsoft.co m> wrote in message
news:32******** *************** ***********@mic rosoft.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(DoW ork));
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.co m>
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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

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.co m>
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******** ******@TK2MSFTN GP11.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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

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.co m>
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******** ******@TK2MSFTN GP15.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******** ******@TK2MSFTN GP11.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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

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.co m>
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(o bject sender, System.EventArg s e)
{
Thread t = new Thread(new ThreadStart(Fil lDG));
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.SetD ataBinding(myDa taSet, "myDataTabl e");
}

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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

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.co m>
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.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Paul <Pa**@discussio ns.microsoft.co m> 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.co m>
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.WaitForPendi ngFinalizers(1) and some
other managed wait API's like WaitHandle.Wait One (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::Relea se 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.WaitForPendi ngFinalizers 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******** ******@TK2MSFTN GP09.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******** ******@TK2MSFTN GP15.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******** ******@TK2MSFTN GP11.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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...
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.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too