Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ MT-multithreading and servers » MT again
MT again [message #24026] Fri, 18 December 2009 12:03 Go to next message
mdelfede is currently offline  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 #24028 is a reply to message #24026] Fri, 18 December 2009 12:51 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
// calculation thread function
void CalcPage::DoCalculation(void)
{
	bool mod;

	INTERLOCKED_(mutex)  {
		inThread = true;
	}
	do
	{
		INTERLOCKED_(mutex)  {
			modified = false;
		}

		// 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;
		}
	}
	while(mod);
	INTERLOCKED_(mutex) {
		inThread = false;
	}
}

// modify handler -- triggers page calculation
// on keypress on every (editable) ctrl on page
void CalcPage::ModifyCb(void)
{
	bool inTh;
	INTERLOCKED_(mutex) {
		inTh = inThread;
	}
	if(!inTh)
	{
		calcThread.Run(THISBACK(DoCalculation));
		return;
	}
	INTERLOCKED_(mutex) {
		modified = true;
	}
}


Well, thanks Mirek ! Smile
I'll post the correct code here for reference.

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).

This snippet allows to have a long time backround calculation without stopping the gui and with results displayed as soon as available.
The thread routine can handle changes in data that happens during the calculation, re-entering itself when finished.

Ciao

Max
Re: MT again (SOLVED!) [message #24029 is a reply to message #24028] Sat, 19 December 2009 11:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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
Re: MT again (SOLVED!) [message #28174 is a reply to message #24029] Fri, 20 August 2010 11:45 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well, just for reference I'll post a bug that drove me crazy for long time Smile
Here the sample code :

void ThreadCb(void)
{
    INTERLOCKED_(mutex) {
        inThread = true;
    }

    << DO SOME TIME CONSUMING STUFFS>

    INTERLOCKED_(mutex) {
        inThread = false;
}

bool StartThread(void)
{
    bool inTh;
    INTERLOCKED_(mutex) {
        inTh = inThread;
    }
    if(inTh)
        return false;
    myThread.Run(ThreadCb);
    return true;
}



Purpose is clear, just start the thread *ONLY* if not already running, return true if success or false if thread was already running.
Where's the caveat ? It's simply in the time BETWEEN the start of ThreadCb() callback and the setting of 'inThread' variable to true. If code calls fast enough the StartThread() routine, it can happen that the Thread callback is in the middle of startup code BUT has still NOT SET the 'inThread' flag; so the StartThread() routine believes thread isn't running and calls it again.
The solution :

void ThreadCb(void)
{
    << DO SOME TIME CONSUMING STUFFS>

    INTERLOCKED_(mutex) {
        inThread = false;
}

bool StartThread(void)
{
    bool inTh;
    INTERLOCKED_(mutex) {
        inTh = inThread;
    }

    if(inTh)
        return false;
    inThread = true;
    myThread.Run(ThreadCb);
    return true;
}



So, I've moved the 'inThread' flag SETTING from the thread routine to its caller; the reset still belong to thread routine.
Now it's the caller that has the responsibility of setting the variable, so it can't happen that thread routine performs some stuffs between check and launch.

Ciao

Max

Re: MT again (SOLVED!) [message #28175 is a reply to message #28174] Fri, 20 August 2010 12:22 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Uuups. Thank you Massimo!

I will have to fix some code Rolling Eyes


Best regards
IƱaki
Re: MT again (SOLVED!) [message #28183 is a reply to message #28175] Fri, 20 August 2010 16:42 Go to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
koldo wrote on Fri, 20 August 2010 12:22

Uuups. Thank you Massimo!

I will have to fix some code Rolling Eyes


Ehehehehe... I had this damn'd bug in my app since loooong time, and couldn't understand why my calculation routine was being called in the middle.
That scrambled qtf text alot, and happened mostly ONLY on app startup, where controls triggered it very quickly upon loading from file.
It took me one day of debugging to find it.

Happy it's useful for you Smile

Ciao

Max
Previous Topic: HttpQuery - not working?
Next Topic: CGI-BIN bug with Apache Server
Goto Forum:
  


Current Time: Thu Mar 28 18:55:12 CET 2024

Total time taken to generate the page: 0.01333 seconds