Threading

[AA2e72E]

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?

 

[Arne Vajhøj]

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

 

[AA2e72E]

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.

 

[Arne Vajhøj]

[...]
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.

Using a shared object to wait for it to complete is not optimal.

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.

I consider Join both a main thing and belonging in good threaded code.

And if some problems happen then you may need to slam the thread down.

Arne

 

[Arne Vajhøj]

[...]
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.

Using a shared object to wait for it to complete is not optimal.

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.

I consider Join both a main thing and belonging in good threaded code.

And if some problems happen then you may need to slam the thread down.

Or to look at it from a different angle: if one does not want a ref
to the Thread object because it is more "fire and forget", then
ThreadPool seems as a better abstraction level than Thread.

Arne

 

[Arne Vajhøj]

Waiting for it to complete is not optimal.

Well - if the code to be executed next requires the code in
thread to be completed then it is pretty optimal.

So once you assume that, who
cares what else about it is "not optimal"?

Since ...

Arne

 

[Arne Vajhøj]

It may or may not be. A raw Thread is much better for long-lived tasks,
and for tasks that must not be interrupted by the termination of the
other foreground threads. ThreadPool is better for short-lived ones.

If the thread has to be long-lived, then it seems to be
reasonable to check if it is actually there.

Arne