the WaitCallBack-handler (PopulateContextTable e.g.) should signal that at the and, maybe in a finally block. If this is called from a GUI-Thread you could call BeginInvoke on one of the Forms methods.
Thank you Christof. These 2 threads are started within a form as worker threads only. They are coded as 2 static method within this form. The 2 threads have no form of its own. How can I then find out when they're both done with their tasks? -- Thanks.
> the WaitCallBack-handler (PopulateContextTable e.g.) should signal that at > the and, maybe in a finally block. If this is called from a GUI-Thread you > could call BeginInvoke on one of the Forms methods.
> Christof
> "Pucca" <Pu...@discussions.microsoft.com> schrieb im Newsbeitrag > news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. How > > do I > > know when they're done with their tasks? Thanks.
You use the Join method on the threads. However, there's a small problem: if you call Join in the UI thread, then you hang the UI.
The usual solution is to use one of the two threads as a "controller", or use a third thread. In the first case, the second thread to be started can be handed a reference to the first thread, and do a Join before it signals that it's finished. If the first thread isn't finished yet, then the second thread will wait on the Join until it is. Therefore, when the second (controller) thread is finished, you know that they're both finishes.
If the two threads are not logically related this way, then it might be nicer to use a third, controller thread: the UI starts the controller, which then starts the two worker threads. The controller then does two Joins, one on each worker thread, and when the two Joins complete, it signals the UI that all is done. This is scalable to an arbitrary number of worker threads.
On Jan 26, 10:35 am, Pucca <P...@discussions.microsoft.com> wrote:
> Thank you Christof. These 2 threads are started within a form as worker > threads only. They are coded as 2 static method within this form. The 2 > threads have no form of its own. How can I then find out when they're both > done with their tasks? > -- > Thanks.
> "Christof Nordiek" wrote: > > Hi Pucca,
> > the WaitCallBack-handler (PopulateContextTable e.g.) should signal that at > > the and, maybe in a finally block. If this is called from a GUI-Thread you > > could call BeginInvoke on one of the Forms methods.
> > Christof
> > "Pucca" <P...@discussions.microsoft.com> schrieb im Newsbeitrag > >news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... > > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. How > > > do I > > > know when they're done with their tasks? Thanks.
> > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulateContextTable)); > > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulatAdTable)); > > > -- > > > Thanks.- Hide quoted text -- Show quoted text -
I now need to return SearchResultCollection from both the thread. But I'm getting error that my code calling the thread has the wrong return type.ThreadPool.QueueUserWorkItem(new WaitCallback(PopulatAdTable));
I have declared my thread method as static SearchResultCollection PopulatAdTabe(object stateInfo) {}
Is there something wrong with my declaration? Thanks. -- Thanks.
"Bruce Wood" wrote: > You use the Join method on the threads. However, there's a small > problem: if you call Join in the UI thread, then you hang the UI.
> The usual solution is to use one of the two threads as a "controller", > or use a third thread. In the first case, the second thread to be > started can be handed a reference to the first thread, and do a Join > before it signals that it's finished. If the first thread isn't > finished yet, then the second thread will wait on the Join until it is. > Therefore, when the second (controller) thread is finished, you know > that they're both finishes.
> If the two threads are not logically related this way, then it might be > nicer to use a third, controller thread: the UI starts the controller, > which then starts the two worker threads. The controller then does two > Joins, one on each worker thread, and when the two Joins complete, it > signals the UI that all is done. This is scalable to an arbitrary > number of worker threads.
> On Jan 26, 10:35 am, Pucca <P...@discussions.microsoft.com> wrote: > > Thank you Christof. These 2 threads are started within a form as worker > > threads only. They are coded as 2 static method within this form. The 2 > > threads have no form of its own. How can I then find out when they're both > > done with their tasks? > > -- > > Thanks.
> > "Christof Nordiek" wrote: > > > Hi Pucca,
> > > the WaitCallBack-handler (PopulateContextTable e.g.) should signal that at > > > the and, maybe in a finally block. If this is called from a GUI-Thread you > > > could call BeginInvoke on one of the Forms methods.
> > > Christof
> > > "Pucca" <P...@discussions.microsoft.com> schrieb im Newsbeitrag > > >news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... > > > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. How > > > > do I > > > > know when they're done with their tasks? Thanks.
> > > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulateContextTable)); > > > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulatAdTable)); > > > > -- > > > > Thanks.- Hide quoted text -- Show quoted text -
"Bruce Wood" wrote: > You use the Join method on the threads. However, there's a small > problem: if you call Join in the UI thread, then you hang the UI.
> The usual solution is to use one of the two threads as a "controller", > or use a third thread. In the first case, the second thread to be > started can be handed a reference to the first thread, and do a Join > before it signals that it's finished. If the first thread isn't > finished yet, then the second thread will wait on the Join until it is. > Therefore, when the second (controller) thread is finished, you know > that they're both finishes.
> If the two threads are not logically related this way, then it might be > nicer to use a third, controller thread: the UI starts the controller, > which then starts the two worker threads. The controller then does two > Joins, one on each worker thread, and when the two Joins complete, it > signals the UI that all is done. This is scalable to an arbitrary > number of worker threads.
> On Jan 26, 10:35 am, Pucca <P...@discussions.microsoft.com> wrote: > > Thank you Christof. These 2 threads are started within a form as worker > > threads only. They are coded as 2 static method within this form. The 2 > > threads have no form of its own. How can I then find out when they're both > > done with their tasks? > > -- > > Thanks.
> > "Christof Nordiek" wrote: > > > Hi Pucca,
> > > the WaitCallBack-handler (PopulateContextTable e.g.) should signal that at > > > the and, maybe in a finally block. If this is called from a GUI-Thread you > > > could call BeginInvoke on one of the Forms methods.
> > > Christof
> > > "Pucca" <P...@discussions.microsoft.com> schrieb im Newsbeitrag > > >news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... > > > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. How > > > > do I > > > > know when they're done with their tasks? Thanks.
> > > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulateContextTable)); > > > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulatAdTable)); > > > > -- > > > > Thanks.- Hide quoted text -- Show quoted text -
Pucca wrote: > I'm using threadpool so I used AutoeventReset and it worked. Thank you very > much.
Be careful: many uses of AutoResetEvent have a race condition, where the event is signaled before anything waits on it, thus causing deadlock when threads do start waiting on it, having "missed the bus", as it were.
AutoResetEvent there is pretty scary. If your "are you done yet?" thread isn't waiting already, then it's going to miss the fact that your work item is complete. This means the order you do things in is very important, and (worse) is also hard to get right.
You would be better served, I suspect, using a ManualResetEvent. This eliminates the problem, and makes your code less likley to have race conditions.
> I'm using threadpool so I used AutoeventReset and it worked. Thank you > very > much. > -- > Thanks.
> "Bruce Wood" wrote:
>> You use the Join method on the threads. However, there's a small >> problem: if you call Join in the UI thread, then you hang the UI.
>> The usual solution is to use one of the two threads as a "controller", >> or use a third thread. In the first case, the second thread to be >> started can be handed a reference to the first thread, and do a Join >> before it signals that it's finished. If the first thread isn't >> finished yet, then the second thread will wait on the Join until it is. >> Therefore, when the second (controller) thread is finished, you know >> that they're both finishes.
>> If the two threads are not logically related this way, then it might be >> nicer to use a third, controller thread: the UI starts the controller, >> which then starts the two worker threads. The controller then does two >> Joins, one on each worker thread, and when the two Joins complete, it >> signals the UI that all is done. This is scalable to an arbitrary >> number of worker threads.
>> On Jan 26, 10:35 am, Pucca <P...@discussions.microsoft.com> wrote: >> > Thank you Christof. These 2 threads are started within a form as >> > worker >> > threads only. They are coded as 2 static method within this form. The >> > 2 >> > threads have no form of its own. How can I then find out when they're >> > both >> > done with their tasks? >> > -- >> > Thanks.
>> > "Christof Nordiek" wrote: >> > > Hi Pucca,
>> > > the WaitCallBack-handler (PopulateContextTable e.g.) should signal >> > > that at >> > > the and, maybe in a finally block. If this is called from a >> > > GUI-Thread you >> > > could call BeginInvoke on one of the Forms methods.
>> > > Christof
>> > > "Pucca" <P...@discussions.microsoft.com> schrieb im Newsbeitrag >> > >news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... >> > > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. >> > > > How >> > > > do I >> > > > know when they're done with their tasks? Thanks.
I always enjoy seeing how I might do the same thing when using my concurrency library. This is actually a pretty common pattern (i.e. scatter/gather). I sample this pattern here http://www.codeplex.com/PCR/Thread/View.aspx?ThreadId=3459
| | > You use the Join method on the threads. However, there's a small | > problem: if you call Join in the UI thread, then you hang the UI. | > | > The usual solution is to use one of the two threads as a "controller", | > or use a third thread. In the first case, the second thread to be | > started can be handed a reference to the first thread, and do a Join | > before it signals that it's finished. If the first thread isn't | > finished yet, then the second thread will wait on the Join until it is. | > Therefore, when the second (controller) thread is finished, you know | > that they're both finishes. | > | > If the two threads are not logically related this way, then it might be | > nicer to use a third, controller thread: the UI starts the controller, | > which then starts the two worker threads. The controller then does two | > Joins, one on each worker thread, and when the two Joins complete, it | > signals the UI that all is done. This is scalable to an arbitrary | > number of worker threads. | > | > On Jan 26, 10:35 am, Pucca <P...@discussions.microsoft.com> wrote: | > > Thank you Christof. These 2 threads are started within a form as worker | > > threads only. They are coded as 2 static method within this form. The 2 | > > threads have no form of its own. How can I then find out when they're both | > > done with their tasks? | > > -- | > > Thanks. | > > | > > | > > | > > "Christof Nordiek" wrote: | > > > Hi Pucca, | > > | > > > the WaitCallBack-handler (PopulateContextTable e.g.) should signal that at | > > > the and, maybe in a finally block. If this is called from a GUI-Thread you | > > > could call BeginInvoke on one of the Forms methods. | > > | > > > Christof | > > | > > > "Pucca" <P...@discussions.microsoft.com> schrieb im Newsbeitrag | > > >news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... | > > > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. How | > > > > do I | > > > > know when they're done with their tasks? Thanks. | > > | > > > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulateContextTable)); | > > > > ThreadPool.QueueUserWorkItem(new WaitCallback(PopulatAdTable)); | > > > > -- | > > > > Thanks.- Hide quoted text -- Show quoted text - | > | >
I think the AutoResetEvent is now cuasing a problem for my code. 1. I dind't find good examples on how to code with manualResetEvent, can you recommend a example on line? 2. Do I need to change my program.cs code's [STAThread] to something else? Is this the Single thread meaning?
"Chris Mullins [MVP]" wrote: > AutoResetEvent there is pretty scary. If your "are you done yet?" thread > isn't waiting already, then it's going to miss the fact that your work item > is complete. This means the order you do things in is very important, and > (worse) is also hard to get right.
> You would be better served, I suspect, using a ManualResetEvent. This > eliminates the problem, and makes your code less likley to have race > conditions.
> "Pucca" <Pu...@discussions.microsoft.com> wrote in message > news:89FCB56F-0EF0-42EB-A5F1-8D80B59B0657@microsoft.com... > > I'm using threadpool so I used AutoeventReset and it worked. Thank you > > very > > much. > > -- > > Thanks.
> > "Bruce Wood" wrote:
> >> You use the Join method on the threads. However, there's a small > >> problem: if you call Join in the UI thread, then you hang the UI.
> >> The usual solution is to use one of the two threads as a "controller", > >> or use a third thread. In the first case, the second thread to be > >> started can be handed a reference to the first thread, and do a Join > >> before it signals that it's finished. If the first thread isn't > >> finished yet, then the second thread will wait on the Join until it is. > >> Therefore, when the second (controller) thread is finished, you know > >> that they're both finishes.
> >> If the two threads are not logically related this way, then it might be > >> nicer to use a third, controller thread: the UI starts the controller, > >> which then starts the two worker threads. The controller then does two > >> Joins, one on each worker thread, and when the two Joins complete, it > >> signals the UI that all is done. This is scalable to an arbitrary > >> number of worker threads.
> >> On Jan 26, 10:35 am, Pucca <P...@discussions.microsoft.com> wrote: > >> > Thank you Christof. These 2 threads are started within a form as > >> > worker > >> > threads only. They are coded as 2 static method within this form. The > >> > 2 > >> > threads have no form of its own. How can I then find out when they're > >> > both > >> > done with their tasks? > >> > -- > >> > Thanks.
> >> > > the WaitCallBack-handler (PopulateContextTable e.g.) should signal > >> > > that at > >> > > the and, maybe in a finally block. If this is called from a > >> > > GUI-Thread you > >> > > could call BeginInvoke on one of the Forms methods.
> >> > > Christof
> >> > > "Pucca" <P...@discussions.microsoft.com> schrieb im Newsbeitrag > >> > >news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... > >> > > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. > >> > > > How > >> > > > do I > >> > > > know when they're done with their tasks? Thanks.
Here is my code where I'm having problem with. It seems like "ThreadPool.QueueUserWorkItem(new WaitCallback (PopulatContextUsersTable), contextUserEvent); " is being executed before the waiting for the 1st 3 threads are done. Is there something wrong with my code or it's the problem with the AutoResetEvent?
Also, would it be better for me to use the BackgrounWorder class? Can this be used for muliple threads as I need it in my code? Thank you.
"Chris Mullins [MVP]" wrote: > AutoResetEvent there is pretty scary. If your "are you done yet?" thread > isn't waiting already, then it's going to miss the fact that your work item > is complete. This means the order you do things in is very important, and > (worse) is also hard to get right.
> You would be better served, I suspect, using a ManualResetEvent. This > eliminates the problem, and makes your code less likley to have race > conditions.
> "Pucca" <Pu...@discussions.microsoft.com> wrote in message > news:89FCB56F-0EF0-42EB-A5F1-8D80B59B0657@microsoft.com... > > I'm using threadpool so I used AutoeventReset and it worked. Thank you > > very > > much. > > -- > > Thanks.
> > "Bruce Wood" wrote:
> >> You use the Join method on the threads. However, there's a small > >> problem: if you call Join in the UI thread, then you hang the UI.
> >> The usual solution is to use one of the two threads as a "controller", > >> or use a third thread. In the first case, the second thread to be > >> started can be handed a reference to the first thread, and do a Join > >> before it signals that it's finished. If the first thread isn't > >> finished yet, then the second thread will wait on the Join until it is. > >> Therefore, when the second (controller) thread is finished, you know > >> that they're both finishes.
> >> If the two threads are not logically related this way, then it might be > >> nicer to use a third, controller thread: the UI starts the controller, > >> which then starts the two worker threads. The controller then does two > >> Joins, one on each worker thread, and when the two Joins complete, it > >> signals the UI that all is done. This is scalable to an arbitrary > >> number of worker threads.
> >> On Jan 26, 10:35 am, Pucca <P...@discussions.microsoft.com> wrote: > >> > Thank you Christof. These 2 threads are started within a form as > >> > worker > >> > threads only. They are coded as 2 static method within this form. The > >> > 2 > >> > threads have no form of its own. How can I then find out when they're > >> > both > >> > done with their tasks? > >> > -- > >> > Thanks.
> >> > > the WaitCallBack-handler (PopulateContextTable e.g.) should signal > >> > > that at > >> > > the and, maybe in a finally block. If this is called from a > >> > > GUI-Thread you > >> > > could call BeginInvoke on one of the Forms methods.
> >> > > Christof
> >> > > "Pucca" <P...@discussions.microsoft.com> schrieb im Newsbeitrag > >> > >news:E805594F-654D-4932-A062-01962A077D10@microsoft.com... > >> > > > Hi, I'm using vs2005 and .net 2.0. I started 2 threadpool threads. > >> > > > How > >> > > > do I > >> > > > know when they're done with their tasks? Thanks.
|
