> > On 27 Apr 2011, at 18:39, kxng wrote: > > > Hello, > >=20 > > I have a question that is not really about fltk, but hope to get some = > helps or approaches from here. > >=20 > > My program has two child threads, thread1 and thread2 spawned from the = > main thread. when a button from the main thread is clicked, it checks = > user's selections on three check boxes. The checks can be in any = > combination, but they always be executed in sequence. > >=20 > > Thread1 is in charge of running three heavy calculations and thread2 = > is in charge of displaying results immediately after each calculation to = > the GUI. I have both threads created in main in the suspended states. = > When the button is clicked, thread1 starts doing his jobs. Once thread1 = > finishes his first job, it resumes thread2 to update the results to the = > screen. In the mean while, thread2 continues to do his second job. > >=20 > > The question I have is how do I put thread2 to pause until thread1 = > finishes his second job, then thread2 can update the results to screen, = > then continue one in this fashion. I do not want to use busy wait loop, = > because it will eat up lots of cpu time. What is the best approach here = > in this case? > >=20 > > Moreover, once thread1 finishes all his tasks, user can input = > different parameters and restart the calculation again with different = > selections. > >=20 > >=20 > > My test code is as followed: > > Your test code is Windows specific, so I can't test it (you can easily = > wrap Windows and Posix threads in wrappers to make your code portable, = > BTW) but my observations are: > > - I'm not even sure you need the second thread, it is quite likely that = > what it is doing could be better done by having thread1 trigger = > callbacks in the main thread via the; > > int Fl::awake (Fl_Awake_Handler func, void *data =3D 0); > > method. This allows you to set a callback (executed in the main thread) = > to do the display updates etc as appropriate. So thread1 can the trigger = > those updates as required, and the updates themselves effectively happen = > in the primary thread, thereby simplifying locking and so forth, and = > essentially removing any chance of problems with updating the GUI form a = > subsidiary thread. > > - If you are dead-set on using a second thread, then you probably need = > to look at using some form of mutex to allow thread2 to block until = > thread1 signals that data is ready. Repeatedly suspending and resuming = > threads is seldom a good idea and is fraught with problems - simply = > having thread2 block until there is something to do is far more likley = > to be robust. > Under Windows, you can do this in a number of ways, e.g. with a mutex or = > a semaphore - though in this case a simple notification event object = > might be the simplest. > Have a brows around on MSDN, particularly the "Using Synchronization" = > pages, and there are loads of examples in there to show you things to = > try. > > >
The reason why I need the second thread is later I might have to output the result more interactively (as soon as thread1 product 1 data point, I draw that data point to the screen), instead of waiting for all data points available before drawing. I was thinking using Event object, but not familiar with it. I need more info about it if possible. Thanks, _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
