Threading
in [CSharp]
|
From: Arne Vajhøj on 30 Jun 2010 22:49 On 30-06-2010 22:23, Peter Duniho wrote: > 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. 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
From: Arne Vajhøj on 30 Jun 2010 22:50 On 30-06-2010 22:26, Peter Duniho wrote: > 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. If the thread has to be long-lived, then it seems to be reasonable to check if it is actually there. Arne
From: Peter Duniho on 30 Jun 2010 22:58 Arne Vajhøj wrote: > On 30-06-2010 22:26, Peter Duniho wrote: >> 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. > > If the thread has to be long-lived, then it seems to be > reasonable to check if it is actually there. Huh? Where would it go? Why would you write code in which a thread could terminate, and the rest of the program needs to know that, but not provide any indication to the rest of the program via the other inter-thread communication techniques?
From: Peter Duniho on 30 Jun 2010 23:00
Arne Vajhøj wrote: > On 30-06-2010 22:23, Peter Duniho wrote: >> 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. > > Well - if the code to be executed next requires the code in > thread to be completed then it is pretty optimal. The whole point of putting something on a thread is to let the current thread keep executing. If you're just going to wait for the other thread to finish, then just execute that code on the current thread instead. If you have some continuation code that needs to execute on a particular thread after the worker thread has completed, that is generally dealt with via a SynchronizationContext or similar mechanism in which the continuation thread is processing a variety of dispatched delegates, rather than just waiting on some particular thread. >> So once you assume that, who >> cares what else about it is "not optimal"? > > Since ... Did you mean to finish that thought? |