Simple Thread Questions

[Meya-awe]

If one calls Thread myThread = new Thread(new
ThreadStart(ThreadProdure)) several times, will each time a new thread
be created with each executing a different instance of the same
procedure? or will the execution of the first ThreadProcedure be
interrupted by the second and so forth?
Is this the same for ThreadPool.QueueUsersWorkItem?
If i want to use ThreadPool.QueueUsersWorkItem, how do i tell it never
to expire since i want this thread to last as long as the application is
running?
thanks,
BRAMOIN

 

[Jon Skeet [C# MVP]]

If one calls Thread myThread = new Thread(new
ThreadStart(ThreadProdure)) several times, will each time a new thread
be created with each executing a different instance of the same
procedure? or will the execution of the first ThreadProcedure be
interrupted by the second and so forth?

It will create several separate threads.

Is this the same for ThreadPool.QueueUsersWorkItem?
If i want to use ThreadPool.QueueUsersWorkItem, how do i tell it never
to expire since i want this thread to last as long as the application is
running?

You shouldn't use the thread pool for long-running tasks - that's not
what it was designed for. However, if you did, there's no concept of
"expiry" of a running thread.

 

[Meya-awe]

Jon, appreciate your quick response. I have read this response in the
MSDN documentation for "threadpool" as well. But to put it politely, to
say that "it was not designed for this" is not a conviencing answer,
why? what was it designed for?

The problem with new Thread is that it does not support passing data to
the thread and one needs to use the threadpool since one can pass the
data inside an developer defined object.

with respect to the expiration, it looks like i pushed the "Send" button
soon. I was refering to the WaitOne method call which has an expiration.
But was running multiple threads in my brain and lost synchronization
.

In any case, it looks like i can call the QueueUsersItem multiple times
and relay on some CLR or OS mechanism to queue my requests or exactly
what happens here?
thanks,
BRAMOIN

 

[jeremiah johnson]

ThreadPools are designed for large amounts of tasks that require short
amounts of time.

 

[Jon Skeet [C# MVP]]

Jon, appreciate your quick response. I have read this response in the
MSDN documentation for "threadpool" as well. But to put it politely, to
say that "it was not designed for this" is not a conviencing answer,
why? what was it designed for?

Short tasks which aren't going to clog it up. There are only 25 threads
(per processor) in the thread pool. If 25 different things decided to
add long-running tasks, there wouldn't be any threads left to run the
short-running tasks.

Besides that, the point of a thread pool is to avoid the cost of
creating a new thread. IF the thread is going to run for a long time,
the cost is pretty insignificant in the long run. With the typical use
of a thread pool, the time spent creating a new thread may even exceed
the time spent running the specified delegate.

The problem with new Thread is that it does not support passing data to
the thread and one needs to use the threadpool since one can pass the
data inside an developer defined object.

That's not a good reason to use the thread pool IMO. There are other
ways to get round that. See

http://www.pobox.com/~skeet/csharp/threads/parameters.shtml

with respect to the expiration, it looks like i pushed the "Send" button
soon. I was refering to the WaitOne method call which has an expiration.
But was running multiple threads in my brain and lost synchronization
.

I'm still not entirely sure I know what you're after here, but using
separate (non-threadpool) threads, you'd probably want to use
Thread.Join.

In any case, it looks like i can call the QueueUsersItem multiple times
and relay on some CLR or OS mechanism to queue my requests or exactly
what happens here?

The thread pool will queue requests if it doesn't have enough threads
available. However, if you really *do* want to use a thread pool, I'd
suggest using a custom-built one rather than the system one. It's very
hard to predict what other methods use the system thread pool, and you
can easily end up with a deadlock which is very hard to diagnose. I
have a thread pool you can use:
http://www.pobox.com/~skeet/csharp/miscutil

 

[Meya-awe]

Jon,
Thanks for your help. I am going to stick with the regular Thread call.
It looks like your utility is very extensive and if i were to include
it, i would have to spend some time to understand it.

Looks like the .join has the effect of joining the thread with the new
so, i am not going to go that route either.

If it is expensive to create a thread everytime there is time consuming
work to be done on arriving data, I would create the thread once. I was
thinking that this thread will sit on a WaitOne for this event.
Everytime, i get data, i will Raise an event that the thread is waiting
on. This is at the concept level, i am not sure if it will work. The
data that the thread operates on, needs to be global to the class where
the thread is defined in.

thanks,
BRAMOIN

 

[Jon Skeet [C# MVP]]

Thanks for your help. I am going to stick with the regular Thread call.
It looks like your utility is very extensive and if i were to include
it, i would have to spend some time to understand it.

Well, some but not a lot. It's not a particuarly tricky interface.

Looks like the .join has the effect of joining the thread with the new
so, i am not going to go that route either.

If it is expensive to create a thread everytime there is time consuming
work to be done on arriving data, I would create the thread once. I was
thinking that this thread will sit on a WaitOne for this event.
Everytime, i get data, i will Raise an event that the thread is waiting
on. This is at the concept level, i am not sure if it will work. The
data that the thread operates on, needs to be global to the class where
the thread is defined in.

Sounds like you're after a producer/consumer queue. See the second half
of http://www.pobox.com/~skeet/csharp/threads/deadlocks.shtml

 

[Meya-awe]

I can't use an MSMQ, this is one of the requirements of the app i am
building. So, i wanted to do a WaitOne until the i have data. When i get
data, i will set a manual event which causes the WaitOne to release and
then i can process the data. The question i have is: When i am
processing this data, if i am in a new thread and i get more data,
setting the manual event does not do anything. Since it is doing the
processing of the first set of data. When processing of the first set is
done, the thread will go back to WaitOne again. Since the manual event
is set, it should process the next data. I am going to put the incoming
data in an ArrayList and protect it using lock. Will this work?

psudeo (forget the modifiers, that is all private -)):

IncomingData(object o)
{
_dataList.Add(o);
manualEvent(true);
}

AnotherThread()
{
while (
{
WaitOne(_manualEvent(indefinitely), ...))

if(incomingData.Msg == SHUT_DOWN)
{
break;
}

processDataList(incomingData.DataList);
}
}

thx!
BRAMOIN