From: AA2e72E on
Are there any dangers with a line of code such as:

new System.Threading.Thread(UpdateContacts).Start();

On completion, does the thread get taken care of by ... what?
From: Peter Duniho on
AA2e72E wrote:
> Are there any dangers with a line of code such as:
>
> new System.Threading.Thread(UpdateContacts).Start();
>
> On completion, does the thread get taken care of by ... what?

Define "taken care of".

But in general, no…it's not a problem to create a thread and start it
without holding a reference to the Thread instance.

Pete
From: Arne Vajhøj on
On 29-06-2010 03:48, AA2e72E wrote:
> Are there any dangers with a line of code such as:
>
> new System.Threading.Thread(UpdateContacts).Start();
>
> On completion, does the thread get taken care of by ... what?

The thread will run and when it completes then it should
be garbage collected.

The code will compile and run predictable.

I think it will be very rare to see such a construct
in real world production code.

You start a thread without being able to check
its status or being able to affect it.

That is not good code. In most cases.

Arne

From: Peter Duniho on
Arne Vajhøj wrote:
> [...]
> I think it will be very rare to see such a construct
> in real world production code.
>
> You start a thread without being able to check
> its status or being able to affect it.
>
> That is not good code. In most cases.

My own experience is exactly the contrary. I've written a fair amount
of multi-threaded code, and when creating an explicit thread I almost
never need the Thread reference itself. Communication to and from the
thread is done through shared memory objects.

Good threading code should not have to inspect the Thread object to
determine the state of the thread, nor should it need the Thread
reference to affect the thread, since the main things you can do to a
Thread using the reference itself are to suspend, resume, interrupt, or
abort it, none of which belong in good threaded code.

Every now and then one might need to set the culture, or during
initialization set things like the Name, Priority, or IsBackground
properties. But even those scenarios really only need a local variable,
and most threading code has no need to modify those values.

Pete
From: AA2e72E on
>Define "taken care of".

I meant to ask, as you have guessed perhaps, whether the thread tidies
itself (presents no issues for GC) on completion or error.

My line is calling a function that invokes a stored procedure refreshes a
SQL Server table - it takes a long time. The application uses this particular
table and the table itself needs to be refreshed every three hours. I decided
to refresh it while the application is in use: it removes the three hour
delay and it matters little that my application MAY use the table before it
is refreshed by the thread.