From: AA2e72E on 29 Jun 2010 03:48 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 29 Jun 2010 10:42 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 29 Jun 2010 20:46 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 29 Jun 2010 23:02 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 30 Jun 2010 01:33
>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. |