A More Effecient Threading?

[Guest]

I am working with an application that requires multithreading. I have found
a sample online that I am currently working with/learning from. However, I
am not sure if this is the most effecient way or most current way of
threading. Here is the sample I have found. I'd appreciate any
feedback/recommendations on better ways to use threading if this sample will
not suffice:

public partial class Form1 : Form
{
private void Form1_Load(object sender, EventArgs e)
{
int iFrom = 0;
int iTo = 5;

LA = new LH[iTo - iFrom + 1];

for (int i = iFrom; i <= iTo; i++)
{
//class defines thread start routine and data
LH Line = new LH();
LH[iTr - iFrom] = Line;

//pass parameters to the new thread
Line.iTr = i;
Line.MainForm = this;
ThreadStart ts = new ThreadStart(Line.ProcessingThread);
Thread wrkThread = new Thread(ts);
Line.CurrentThread = wrkThread;
wrkThread.SetApartmentState(ApartmentState.STA);
//default is MTA
wrkThread.Name = i.ToString(); //for easier tracing
wrkThread.Start();
Thread.Sleep(2000); //add some time for processing
}
}


public class LH
{
public Form1 MainForm = null;
public int iTr = -1;
public Thread CurrentThread = null;

public void ProcessingThread()
{
int iThreadId = CurrentThread.GetHashCode();
try
{
//events here
}
catch (COMException e)
{
return;
}
catch (Exception e)
{
return;
}

Application.Run();
}
}

Thanks for the assistance.

 

[Marc Gravell]

Hang on...

Form_Load: you have a Sleep() in you UI code... (after starting the
worker thread) - plus you are creating a whole pile of worker threads
(6 in this case, due to <= iTo) - *each* of which thinks it is running
Application.Run() [at the same time]

Is this what you expected? You are also expecting COM execptions but
not really touching COM?

Personally, I think that Jon's pages are very good on threads:
http://www.yoda.arachsys.com/csharp/threads/

But the bigger question would be: what are you trying to do on each of
these threads, and why? And which are UI threads?

Marc

 

[Marc Gravell]

Also: it is not necessary to pass the "current" thread to the worker;
the worker can get this more reliably via Thread.CurrentThread; and it
would be better to use the ManagedThreadId than the hash-code
(although I seem to recall reading that the hash-code should be unique
for threads; not a guarantee [from me] though!).

Note also that Jon's article spans several pages, not just the one...

IMO, I think you have found a duff sample online... or maybe that
sample is trying to do something *very specific* that doesn't relate
to the general case.

As a final thought: the ThreadPool and BackgroundWorker classes offers
good alternatives to creating your own threads this way. I'm pretty
sure Jon covers both of these.

Marc

 

[Guest]

Thanks for the reply. Actually there is a COM component involved that needs
to be initialized 6 times in 6 different threads. The sleep methd seems to
allow the COM component to initialize properly without generating errors.
The COM component seems to need a few seconds per thread to initialize. I
will definately loo at Jon's article. Thanks a lot for the reply. I
appreciate it.

 

[Jack Brown]

Thanks for the reply. Actually there is a COM component involved that

needs to be initialized 6 times in 6 different threads. The sleep methd
seems to allow the COM component to initialize properly without generating
errors. The COM component seems to need a few seconds per thread to
initialize. I will definately loo at Jon's article. Thanks a lot for the
reply. I appreciate it.

Just an FYI that whenever I hear the term "thread" and "Sleep" in the same
sentence(s) I normally shudder. Thread synchronization should *not* be
carried out with "Sleep()" statements. The time you specify is not only
arbitrary and a waste of time (waiting, say, 2 seconds for a thread to
finish something that takes it a fraction of that time perhaps - this can
also add up if it occurs in a loop and/or many times in your program), but
it's potentially dangerous if the thread finishes sleeping but the thread it
was waiting for hasn't completed its work yet. Use proper synchronization
techniques such as an event semaphore ("ManualResetEvent" for instance).