Threading
in [CSharp]
|
From: Peter Duniho on 30 Jun 2010 03:32 AA2e72E wrote: >> 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. For an operation that simply requires to be invoked on some periodic schedule, it would be better to just use a Timer (any of the three versions available in .NET would do, though for non-GUI stuff, the System.Threading.Timers or System.Timers.Timer would probably be best). Dedicating a whole thread just to call a single function every three hours is a bit wasteful. But in answer to the specific question, no…nothing fundamentally broken will occur due to failing to preserve the Thread object reference. Pete
From: Arne Vajhøj on 30 Jun 2010 20:37 On 29-06-2010 23:02, Peter Duniho wrote: > 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. 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
From: Arne Vajhøj on 30 Jun 2010 21:03 On 30-06-2010 20:37, Arne Vajhøj wrote: > On 29-06-2010 23:02, Peter Duniho wrote: >> 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. > > 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
From: Peter Duniho on 30 Jun 2010 22:23 Arne Vajhøj wrote: > Using a shared object to wait for it to complete is not optimal. Waiting for it to complete is not optimal. So once you assume that, who cares what else about it is "not optimal"? > I consider Join both a main thing and belonging in good threaded code. I don't. > And if some problems happen then you may need to slam the thread down. You should never have to do that to threads executing code you own. In the _much_-less-common case where you're executing third-party code in your thread, it might be necessary, but note that in that case, the third-party code may or may even be interruptible/abortable. Pete
From: Peter Duniho on 30 Jun 2010 22:26
Arne Vajhøj wrote: > 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. 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. Pete |