Threading - Is This Clever or Stupid?

G

Guest

Hi All,

Just a general threading question. Would it be considered good programming
practice, or a bad idea, or whatever, to create a thread with a special name
in order to "pass parameters" to the thread.

In other words, something like this simple example:

btnRunThreads_Click(object sender, EventArgs e)
{
for (int i = 1; i <= 10; i++)
{
ThreadStart workerStart = new ThreadStart(StartMethod);
Thread workerThread = new Thread(workerStart);
workerThread.Name = "Worker_" + i.ToString();
workerThread.Start();
}
}

void StartMethod()
{
Thread thisThread = Thread.CurrentThread;
string threadName = thisThread.Name;
string Task = threadName.Substring(threadName.IndexOf("_") + 1);

switch (Task)
{
case "1":
DoTaskOne();
break;

case "2":
DoTaskTwo();
break;

// More cases, etc.

case "10":
DoTaskTen();
break;

default:
break;
}
}

More "parameters" could be added by continuing to use a separator character
(probably an underscore, since it needs to be a valid thread name), and using
(for instance) the string.split command to enumerate them.

What say you, oh wise ones?

Thanks,
pagates
 
T

Tim Haughton

pagates said:
Hi All,

Just a general threading question. Would it be considered good programming
practice, or a bad idea, or whatever, to create a thread with a special name
in order to "pass parameters" to the thread.

Bad in so many ways ;¬)

Because ThreadStart methods can't take arguments, what you would normally do
is set up member variables to hold the arguments, then call a parameterless
method which effectively collects those variables and pass them into your
real worker method.

Another thing, it is usually considered bad practice to create threads in a
loop.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
 
O

orekinbck

I would not call myself a wise one. Although I like the idea. Bearded
with white hair blowing in the wind as I sit atop a mountain reflecting
on the passing of time.

Ah f@ck it, I'll probably turn out to be a dirty old man who whinges
about the good ole days and always forgets where he left his false
teeth.

Anyways, IMHO, your approach should run OK but I would find it hard to
read if I needed to maintain the code. I would be inclined to split
things up before you start off the threads. You should be able to work
out what you are going to do before you set off the thread, so you can
kick off the relevant routine straight away.

Here are some words of wisdom for you - Man who go through turnstiles
sideways going to Bangkok

For what it is worth
Bill
 
G

Guest

Hi Tim,

Thanks for the feedback. Just some clarifications for me to make...

I realize that "thread loops" aren't a great idea - I was just looking to
make a quick-n-dirty example. Perhaps a better example (although, again,
quick-n-dirty, and off the top of my head) would be a recurisive database
search, based on a parent-child heirarchy.

Assuming proper care was taken to make sure there weren't a runaway number
of threads, a search could be done that says "check all children of this
parent to see if it fits the criteria." Then, a thread could be started for
the children of that parent, and so on. In that case, it seems difficult to
set member variables, as you don't know when a certain search starts or ends.

As an aside, why are threads parameterless (since data is available anyway
by using member variables)?

Thanks again,
pagates
 
N

Nicholas Paldino [.NET/C# MVP]

pagates,

Threads are no longer parameterless. You can now pass a
ParameterizedThreadStart delegate (which is a function which takes one
object parameter) and call the overload of Start that takes a parameer.

Hope this helps.
 
T

Tim Haughton

pagates said:
Hi Tim,

Thanks for the feedback. Just some clarifications for me to make...

I realize that "thread loops" aren't a great idea - I was just looking to
make a quick-n-dirty example. Perhaps a better example (although, again,
quick-n-dirty, and off the top of my head) would be a recurisive database
search, based on a parent-child heirarchy.

Create a "Composite Pattern"-like object that manages a query of it's
children, each node then manages the asynchronous searching of its children.

Still not a good use of threading, but it should answer your hypothetical
question.

A question for you though, in the example of a recursive database search,
why would you need more than 1 worker thread?

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
 
N

Nicholas Paldino [.NET/C# MVP]

Well, that's a matter of choice. The beta is out, and you can create
apps now (the API has been locked down pretty much as well, so you won't
have to worry about changes). The bits are out there, for everyone who
wants to use them.

If you are releasing your app in the next three months, I would say
fine, but if your release/lauch date is after that, I would say working with
the beta now would be a good idea.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Tim Haughton said:
in
message news:[email protected]...
pagates,

Threads are no longer parameterless. [Snip]

Not entirely true, the version of the framework you refer to isn't
released
for another 3 months. Threads *will* no longer be parameterless upon its
release. :)

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top