|
|
Home » U++ Library support » U++ MT-multithreading and servers » MT again
MT again [message #24026] |
Fri, 18 December 2009 12:03 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
// calculation thread function
void CalcPage::DoCalculation(void)
{
int mod;
INTERLOCKED_(mutex) {
modified = false;
}
do
{
LOG(__FUNCTION__ << " Start calculation");
// gets the status bar
StatusBar &sb = ((Lamell *)(GetMainWindow()))->GetStatusBar();
{
// signals calculation in progress
GuiLock __;
sb.Set("Calcolo in corso");
}
calcAborted = !Calculate();
{
// signals end of calculation
GuiLock __;
if(calcAborted)
sb.Set("Errore");
else
sb.Set("Pronto");
}
INTERLOCKED_(mutex) {
mod = modified;
}
LOG(__FUNCTION__ << " End calculation, modified = " << mod);
}
while(mod);
}
// modify handler -- triggers page calculation
// on keypress on every (editable) ctrl on page
void CalcPage::ModifyCb(void)
{
LOG(__FUNCTION__ << " ModifyCb called");
if(!calcThread.IsOpen())
{
calcThread.Run(THISBACK(DoCalculation));
return;
}
INTERLOCKED_(mutex) {
modified = true;
}
}
CalcPage::ModifyCb is called on every change on editables ctrls on page (editfields mostly)
DoCalculation thread should take in account changes on page that happens between calculations, and so it should recalc the whole stuff.
My results :
Sometimes it starts just once, then it's never run again (the calc thread), so I guess it's hanging somewhere
Sometimes it keeps recalculating, but ModifyCb is not reentered, so I'm quite sure that the modify flag is not recursively set because of calc routine.
First case happens mostly
Max
|
|
|
|
Re: MT again (SOLVED!) [message #24029 is a reply to message #24028] |
Sat, 19 December 2009 11:55 |
|
mirek
Messages: 13984 Registered: November 2005
|
Ultimate Member |
|
|
mdelfede wrote on Fri, 18 December 2009 06:51 | The problem was that IsOpen() just checks that the thread was STARTED right, not if the thread is still active.
To check for it, I added a new variable set inside the thread (inThread).
|
Well, I have spent some time thinking about the issue and came to the conclusion that IsOpen behaviour is in fact correct:
Even if thread is finished (returns from the thread routine), its OS representation still exists until the last reference to the thread is closed.
For example, in such situation, call to Wait returns immediately.
This behaviour is in fact required for correct thread synchronisation - it is always possible that thread finishes quick, but you still need to know that it has started successfully.
I was also thinking about adding IsRunning method, but for now I am against it - such status is very temporal thing, I am afraid that such method is invitation for race conditions to emerge.
Mirek
|
|
|
|
|
|
Goto Forum:
Current Time: Wed Jun 05 10:06:29 CEST 2024
Total time taken to generate the page: 0.01836 seconds
|
|
|