Array of Threads

[Guest]

Hello,
I am creating server service. This service will be read data from SQL
server. Base on these data will create threats. These threads will still
working. I must know some pointers on these threads becouse I want to
stop and start these threads. Which of data structures are the best for
this.

Thank you for feedback.
J.H.

 

[Jon Skeet [C# MVP]]

I am creating server service. This service will be read data from SQL
server. Base on these data will create threats. These threads will still
working. I must know some pointers on these threads becouse I want to
stop and start these threads. Which of data structures are the best for
this.

Sounds like either an ArrayList or straight array would be fine.

However, I don't usually find I need to use something like this - it's
better to stop worker threads co-operatively with flags, so I don't
tend to hang onto thread references after creating and starting them.

See
http://www.pobox.com/~skeet/csharp/threads/shutdown.html

 

[Chris Mullins]

[...]
I don't tend to hang onto thread references after
creating and starting them.

I've always done just the opposite - I make sure to keep the thread
references around.

This lets me, in my Shutdown Code, do:

_threadStopEvent.Set()
Dim didStop as Boolean = _myThread.Join(some timeout)
If Not didStop then
_thread.die,die,die
End If

This way i can be _sure_ the thread has stopped. It always drives me nuts to
have my application exit, but still have a single thread running in the
background (I seem to see threads stuck in an an async socket method during
the shutdown process more often than I should)

 

[Jon Skeet [C# MVP]]

[...]
I don't tend to hang onto thread references after
creating and starting them.

I've always done just the opposite - I make sure to keep the thread
references around.

This lets me, in my Shutdown Code, do:

_threadStopEvent.Set()
Dim didStop as Boolean = _myThread.Join(some timeout)
If Not didStop then
_thread.die,die,die
End If

This way i can be _sure_ the thread has stopped. It always drives me
nuts to have my application exit, but still have a single thread
running in the background (I seem to see threads stuck in an an async
socket method during the shutdown process more often than I should)

In that case you need to be very careful to make sure you keep track of
*all* the threads. Far simpler would be to start a background timer of
(say) 5 seconds that then called Environment.Exit to forcibly shut down
the process. If all the foreground threads finish before the timer
ticks, the process will die earlier.

 

[Chris Mullins]

In that case you need to be very careful to make sure you keep track of
*all* the threads. Far simpler would be to start a background timer of
(say) 5 seconds that then called Environment.Exit to forcibly shut down
the process. If all the foreground threads finish before the timer
ticks, the process will die earlier.

i hadn't though of that approach before - it's definatly got some strong
points and I'll probably use it moving forward.

The only downside that I see is (in the general case) if my app has shutdown
issues that are related to threading, it's a good indicator that I've got
some bugs still to work out.

Doing Environment.Exit would mask those bugs from me (or let me be lazy
about fixing them), and would probably come back to haunt me sometime down
the line...

I'm so looking forward to "control.invoke" and that whole mess disappearing
in the next version. That'll probably solve 1/2 my thread issues all by
itself. (Both the ones that I create, and the ones that I fix 'cause someone
else didn't do it right. Ugh. )

 

[Jon Skeet [C# MVP]]

i hadn't though of that approach before - it's definatly got some strong
points and I'll probably use it moving forward.

The only downside that I see is (in the general case) if my app has shutdown
issues that are related to threading, it's a good indicator that I've got
some bugs still to work out.

That's true.

Doing Environment.Exit would mask those bugs from me (or let me be lazy
about fixing them), and would probably come back to haunt me sometime down
the line...

Well, you can use whatever you'd normally use after Join() failed -
write a log message, show a message box, whatever. Admittedly you've
then got less information about what threads were still running,
unfortunately (It would be nice to be able to get a list of active
managed threads, so you could at least print out their names...)

I'm so looking forward to "control.invoke" and that whole mess disappearing
in the next version. That'll probably solve 1/2 my thread issues all by
itself. (Both the ones that I create, and the ones that I fix 'cause someone
else didn't do it right. Ugh. )

In what way is it disappearing? I hadn't heard anything about that. I
think that with Avalon (in Longhorn) controls will throw exceptions
immediately if they're accessed from the wrong threads, but it won't
mean you don't have to do the same kind of work. Maybe I've missed
something though - do you have a link?

 

[Chris Mullins]

In what way is it disappearing? I hadn't heard anything about that.

I would have sworn I read about that, it it was fixed (read: eliminated) in
Whibdey by making all the control fullly free-threaded. It was some time ago
though...

 

[Austin Ehlers]

On Thu, 26 Aug 2004 00:00:30 +0100, Jon Skeet [C# MVP]

In what way is it disappearing? I hadn't heard anything about that. I
think that with Avalon (in Longhorn) controls will throw exceptions
immediately if they're accessed from the wrong threads, but it won't
mean you don't have to do the same kind of work. Maybe I've missed
something though - do you have a link?

..NET 2.0 will throw an ("InvalidOperationException", "Illegal
cross-thread operation: Control 'xxx' accessed from a thread other
than the thread it was created on.") if a control isn't accessed from
either the thread it was created on or by Invoke, BeginInvoke,
EndInvoke, or CreateGraphics.

Austin