Best location to start a thread

[Carl Heller]

If I'm creating a class to do some work that I want threaded out, where's
the best location to call ThreadStart? Or does it depend on the nature of
the work?

a. Call it outside the class, giving it the starting method of the class?
b. Have the class create the thread itself?

ie:
x = new WorkerClass();
ioThread = new Thread(new ThreadStart(x.StartWork));
ioThread.Start();

...

Class WorkerClass
{
...

public void StartWork()
{
SomeMethod();
}
}


or
x = new WorkerClass();
x.StartWork();

...

Class WorkerClass
{
private Thread WorkerThread;
...

public void StartWork()
{
WorkerThread = new Thread(new ThreadStart(this.SomeMethod));
WorkerThread.Start();
}
}

 

[Guest]

I think its best to have it in the class. Its then encapsulated which is a
principle of OO. I also think its better to ThreadPool.QueueUserWorkItem
rather than make a new thread as there is overhead in thread creation.

 

[DeveloperX]

I agree with Ciaran. It gives you the opportunity to do what I've done
in the following example, notably derive a class and override what the
worker does without affecting what the base class does.

#region Example 4
public class Threads4
{
static readonly object _countLock = new object();
private int _count = 0;
public Threads4()
{
}
public void ThreadBasics()
{
ThreadStart myThreadStart = new ThreadStart(ThreadMethod);
Thread myThread = new Thread(myThreadStart);
myThread.Start();
for(int i = 1 ; i<=5 ; i++)
{
Console.WriteLine("Main thread {0}",i);
Thread.Sleep(500);
}

}
protected virtual void ThreadMethod()
{
for(int i = 1 ; i<=5 ; i++)
{
Console.WriteLine("Child thread {0}",i);
Thread.Sleep(750);
}
}
}
public class Threads4b : Threads4
{
public Threads4b()
{
}
protected override void ThreadMethod()
{
for(int i = 1 ; i<=5 ; i++)
{
Console.WriteLine("Derived child thread {0}",i);
Thread.Sleep(750);
}

}
}
#endregion


Alternatively, If you want it to work on different external objects, I
personally would have each implement an interface, then the main object
would take that interface as a parameter and start worker method using
that parameter, ie:

public interface IThreadThis
{
void WriteSomething(int pCount);
}
public class Threads5
{
IThreadThis _threadThis;
public Threads5()
{
}
public void ThreadBasics(IThreadThis pThreadThis)
{
_threadThis = pThreadThis;
ThreadStart myThreadStart = new ThreadStart(ThreadMethod);
Thread myThread = new Thread(myThreadStart);
myThread.Start();
for(int i = 1 ; i<=5 ; i++)
{
Console.WriteLine("Main thread {0}",i);
Thread.Sleep(500);
}

}
protected virtual void ThreadMethod()
{
for(int i = 1 ; i<=5 ; i++)
{
_threadThis.WriteSomething(i);
Thread.Sleep(750);
}
}
}
public class Test1 : IThreadThis
{
public void WriteSomething(int pCount)
{
Console.WriteLine("Test1 {0}",pCount);
}
}
public class Tets2 : IThreadThis
{
public void WriteSomething(int pCount)
{
Console.WriteLine("Test2 {0}",pCount);
}
}

There are plenty of other ways of doing it, and you might find the
above unsuitable for your specific needs, so don't feel railroaded into
one man's idea of good practice

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi

It all depends of what you are doing, the example you are providing is a
great way to pass parameter to the thread (you pass them in the
constructor).
Also helps you to prevent possible errors in concurrency.

Of course if the thread needs access to the creating instance ( if it's a
form and the thread needs to update the UI) then is better to define the
threaded method as an instance method of the calling class.

 

[Carl Heller]

Thank you for your suggestions. Reading this newsgroup always teaches me
something.

That interfaces idea wasn't something I previously would have even thought
of.

Carl.

 

[Chris Mullins [MVP]]

If I'm creating a class to do some work that I want threaded out, where's
the best location to call ThreadStart? Or does it depend on the nature of
the work?

a. Call it outside the class, giving it the starting method of the class?
b. Have the class create the thread itself?

My general rule of thumb is:
If I'm in a client application, I try to use threadpool threads. This
eliminates much of the thread managment, and helps keep my application that
much less complex.

If I'm in a server application, I manage my own threads. I tend to go with
option "B". Generally, I try to keep knowledge of the thread encapsulated
inside a class, so that external classes don't need to worry about it.

 

[Marc Gravell]

Interesting; I'd have thought that *for short lived threads* (to avoid
starvation) the server scenario would benefit *more* from
thread-pooling, since it will typically be serving more disparate
requests, and hence firing up more (briefly) threaded operations. Of
course, for longer running operations I prefer my own threads for more
control (naming, simple joining, avoiding pool starvation [although
you'd have to be massively threaded for this to be an issue]).

It is also harder to accidentally wabbit the thread-pool ;-p (ahh, the
fun "learning experiences" that stay in our minds...)

Marc

 

[Jon Skeet [C# MVP]]

Interesting; I'd have thought that *for short lived threads* (to avoid
starvation) the server scenario would benefit *more* from
thread-pooling, since it will typically be serving more disparate
requests, and hence firing up more (briefly) threaded operations.

Yup, but I'd still avoid using the system threadpool where possible.
It's quite easy to deadlock the system threadpool if one thread
(already in the pool) takes some action which requires another
threadpool thread in order to complete.

I'd recommend using a custom threadpool for custom jobs. Of course, if
..NET provided a way of creating *instances* of threadpools instead of
just having a single one, this wouldn't be an issue...

Jon

 

[Marc Gravell]

Fair points

Marc