×

Discussion Board

Results 1 to 15 of 15
  1. #1
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Starting a thread that causes the main thread to halt

    Hello,

    I am working on an application that integrates camera, opengl, sensors, and Bluetooth. In my current implementation all of these are implemented using active objects. The problem i am facing is that these objects are fighting for the processor time and thus causing a delay for each other. For example the camera frames are being processed properly and displayed in screen but opengl operations are being delayed. When i remove the camera opengl works just fine and as expected. I thought a solution for this would be to change the priority for the objects. However, i do not have access to the AO of the camera or the sensors so this does not really help. An alternative is to split the different functionalities in different threads. Now i am trying the camera to run on one thread separately but i am having a strange behavior.

    When the main thread creates the new thread, which handles the camera, the frames are recieved normally but the main thread does not resume. It hangs there and only the new thread runs (feeding in the camera frames). This for me does not look like mult-threaded behaviour. It is more of processor handing-over instead (ie the main thread hands over the processor to the new one and waits until the later finishes). I am not sure if i am misunderstanding something about threads in Symbian but i would appriciate clarification about this if any one can help.

    I would provide code if needed
    Thanx in advance
    AF

  2. #2
    Super Contributor
    Join Date
    Mar 2004
    Location
    Singapore
    Posts
    9,968

    Re: Starting a thread that causes the main thread to halt

    I think you should try re-designing you logic to divide each process in small parts then use the state machine approach agree the threads are always tempting but on mobile devices try avoiding it

  3. #3
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Re: Starting a thread that causes the main thread to halt

    Thank you skumar_rao for your comment. I know that using threads should be avoided. But i have not option i think using a switch might not be helpfull in my case as i will need all the information from teh AOs to be real-time. The switch will delay something whilst processing another thing.... This is what i think the outcome will be

    Do you have any idea why the main thread is hanging when i start the new thread?

    AF

  4. #4
    Super Contributor
    Join Date
    Nov 2004
    Location
    Wiltshire, UK
    Posts
    3,644

    Re: Starting a thread that causes the main thread to halt

    It sounds like the OpenGL stuff is waiting for the image to be made available from the camera. Does it improve if you drop the camera down to the lowest resolution?

    You can also run the performance investigator and see if the problem is transferring data around (between the camera image and the OpenGL API's/DSP) or if it is something in your code.
    Download Symbian OS now! [url]http://developer.symbian.org[/url]

  5. #5
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Re: Starting a thread that causes the main thread to halt

    Thanks Paul for your reply.
    I am debugging this on the device and i can see that the frames are being tertreived. OpenGL is not waiting for any thing at all. I am constructing the Container and in its constructor i am creating the new thread which is constructing the Camera logic, and after that i am constructing and initiating OGL in the container constructor.

    This is part of my code

    Code:
     
    void CMyAppAppView::ConstructL(const TRect& aRect)
        {
        iOpenGlInitialized = EFalse;
        CreateWindowL();
        SetExtentToWholeScreen();             
        ActivateL();
        iThrdEng = CMyCamThrdEngine::NewL();   // Creates the new thread and receives camera frames
        InitOGL();  /// this function is never reached as the previous one never returns
        }
    
    void CMyAppAppView::InitOGL()
        {
        // ...
        // EGL initialization
        //
        iSimpleCube = CSimpleCube::NewL( size.iWidth, size.iHeight ); // Create an instance of SimpleCube
        iSimpleCube->AppInit();                                       // Initialize OpenGL ES
        iOpenGlInitialized = ETrue;
        iPeriodic = CPeriodic::NewL( CActive::EPriorityStandard );         // Create an active object for
        iPeriodic->Start( 100, 100, TCallBack( CMyAppAppView::DrawCallBack, this ) );
        }
    
     TInt CMyAppAppView::DrawCallBack( TAny* aInstance )
         {
         CMyAppAppView* instance = (CMyAppAppView*) aInstance;
         instance->iFrame++;
    
         if( instance->iCamThrdEng->Initialised() )
        	 {
    	 // Call the main OpenGL ES Symbian rendering 'loop'
    	 instance->iSimpleCube->AppCycle( instance->iFrame, instance->iTiltaniumEng->Texture() );
        	 // Call eglSwapBuffers, which blit the graphics to the window
    	 eglSwapBuffers( instance->iEglDisplay, instance->iEglSurface );
        	 }
    
    /*   if ( !(instance->iFrame%50) )
             {
             User::After(0);
             }*/
    
         return 0;
         }
    
    //
    // Creating the thread responssible of camera processing
    //
    CCamThrdEngine* CCamThrdEngine::NewL()
    	{
    	CCamThrdEngine* self = new(ELeave) CCamThrdEngine();
    	CleanupStack::PushL(self);
    	self->ConstructL();
    	CleanupStack::Pop();
    	return self;
    	}
    
    CCamThrdEngine::CCamThrdEngine() : CActive(EPriorityStandard)
    	{
    	CActiveScheduler::Add(this);
    	}
    
    CCamThrdEngine::~CCamThrdEngine()
    	{
    	TerminateThread();	
    	delete iTexPtr;
            // Camera controller 
            if( iController )
    	    {
    	    delete iController;
    	    }
    	}
    
    void CCamThrdEngine::ConstructL()
    	{
    	if( CreateThread() == KErrNone )
    		{
    		StartThread();
    		}
    	}
    
    TInt CCamThrdEngine::TerminateThread()
    	{
    	Cancel();
    	iThread.Close();
    	}
    	
    TInt CCamThrdEngine::StartThread()
        {
        TInt ret = KErrNone;
        if(!IsActive())
            {
            // Requests notification when this thread dies
            iThread.Logon(iStatus);
            SetActive();
            iThread.Resume();
            User::After(1000000); // Sleep for a while to allow the new thread to start.
            }
        else
            {
            ret = KErrOverflow;
            }
        return ret;
        }
    
    TInt CCamThrdEngine::CreateThread()
        {
        TInt ret = iThread.Create(_L("TiltaniumThrd"), 
        CCamThrdEngine::ThreadeEntryPoint, KDefaultStackSize, NULL, this);			
        return ret;
        }
    
    TInt CCamThrdEngine::ThreadeEntryPoint( TAny* aPtrThis)
        {
        // Creating the cleanup stack for the thread
        CTrapCleanup* cleanupStack = CTrapCleanup::New();
    
        TRAPD( err, ((CCamThrdEngine*) aPtrThis)->DoThreadActionL() );
        __ASSERT_ALWAYS(!err, User::Panic(_L("Thread panic"),err));
    
        // deleting the cleanup stack for the thread
        delete cleanupStack;
        return 1;
        }
    
    void CCamThrdEngine::DoThreadActionL()
        {
        // Create an active scheduler
        CActiveScheduler* activescheduler = new(ELeave) CActiveScheduler();
        CleanupStack::PushL(activescheduler); 
        // Install the active scheduler 
        CActiveScheduler::Install(activescheduler);
    
        TSize sz(344,256);
        iController = new (ELeave) CCameraController(*this);
        CleanupStack::PushL(iController);
        iController->ConstructL(sz);
        CleanupStack::Pop(); 
        
        CActiveScheduler::Start();	// The furthest point i reach by debugging
        CActiveScheduler::Install(NULL);
        CleanupStack::PopAndDestroy(activescheduler);   	
        }
    	
    // This is the callback function called by MCameraObserver::ViewFinderFrameReady(CFbsBitmap& aFrame)
    // This function is constantly called, that means the thread is still alive and working but it is blocking the main one
     void CCamThrdEngine::DrawScreens(CFbsBitmap &aFrame)
        {
        if( iTexPtr )
    	{
    	CopyDataAddress(&aFrame, iTexPtr);
    	}
        else
    	{
    	iTexPtr = new(ELeave) TUint8[MAX*3];
    	CopyDataAddress(&aFrame, iTexPtr);
    	}
        }
    
     void CCamThrdEngine::RunL()
        {
        // Not called at all
        }
    
     void CCamThrdEngine::DoCancel()
        {
        iThread.LogonCancel(iStatus);
        iThread.Kill(KErrCancel);
        }

  6. #6
    Super Contributor
    Join Date
    Nov 2004
    Location
    Wiltshire, UK
    Posts
    3,644

    Re: Starting a thread that causes the main thread to halt

    What does CopyDataAddress do?

    I speculate it probably a heap contention issues with the bitmap server bearing in mind the bitmap is probably > 64K
    There is a similar thread going on here http://discussion.forum.nokia.com/fo...391#post550391.
    Download Symbian OS now! [url]http://developer.symbian.org[/url]

  7. #7
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Re: Starting a thread that causes the main thread to halt

    I think the link you provided is wrong as it directs to this same thread

    CopyDataAddress acually take a pointer to the DataAddress of the pitmap and copies it to TUint8 array, for later processing. No much clever stuff in there. A loop that goes throught the returned dataaddress array and copies its content to the otehr array.

    The bitmap frames are actually 16MU.

  8. #8
    Super Contributor
    Join Date
    Nov 2004
    Location
    Wiltshire, UK
    Posts
    3,644

    Re: Starting a thread that causes the main thread to halt

    Which device are you running this on?

    The corrected link is http://discussion.forum.nokia.com/fo...d.php?t=160168
    Download Symbian OS now! [url]http://developer.symbian.org[/url]

  9. #9
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Re: Starting a thread that causes the main thread to halt

    Nokia 6210

  10. #10
    Super Contributor
    Join Date
    Nov 2004
    Location
    Wiltshire, UK
    Posts
    3,644

    Re: Starting a thread that causes the main thread to halt

    Wat is the size of MAX and what is the size of the data you are trying to copy?

    I would also put some logging in DrawCallBack or at least increase the interval of the CPeriodic as remember you only have a 400mz processor which is also performing baseband functionality
    Last edited by Paul.Todd; 2009-03-02 at 00:31.
    Download Symbian OS now! [url]http://developer.symbian.org[/url]

  11. #11
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Re: Starting a thread that causes the main thread to halt

    MAX = 128x256 (a portion of the camera frame)

    DrawCallBack is never reached as InitGL is not called whatsoever, because the main thread hangs after creating and resuming the second thread. So, changin CPeriodic would do no effect since it is not executed.

    What is your point behind mentioning that there is a 400MHz processor?

  12. #12
    Super Contributor
    Join Date
    Nov 2004
    Location
    Wiltshire, UK
    Posts
    3,644

    Re: Starting a thread that causes the main thread to halt

    I don't know what the problem is, if it was me I would run the performance investigator and see whether the CPU is saturated moving memory around, though I think there is an implicit mutex somewhere that is blocking the threads.

    You could try adding a User::After(0) in the CCamThrdEngine:rawScreens method and also try commenting out the contents of CopyDataAddress and see if that has any effect. If it does you have at least isolated the problem to a single function.

    I'm also a bis suspicious about the User::After not returning - have you removed all breakpoints and put a single one after this then let the debugger run? I might be that the debugger is interfering with the scheduling of the other thread and the other thread has not had a chance to run.

    I was just pointing out that these devices are very underpowered compared to desktop machines (and single CPU phones even more so since they are sharing the chip) and so doing stuff like moving large blocks of memory around are considerably slower than the equivalent desktop operations.
    Download Symbian OS now! [url]http://developer.symbian.org[/url]

  13. #13
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Re: Starting a thread that causes the main thread to halt

    well this makes a lot of sense now

    I might be that the debugger is interfering with the scheduling of the other thread and the other thread has not had a chance to run.
    It appears that when i build the project for release the app works fine on the phone (with poor performance still)! But when i am debuging on the device the multithreading does not work for some reason. Thanks for pointing this out.

    Now i will return to AOs use since i did not find much difference in performance between using AOs and multi threads (at least in this case)

    Cheers

  14. #14
    Super Contributor
    Join Date
    Nov 2004
    Location
    Wiltshire, UK
    Posts
    3,644

    Re: Starting a thread that causes the main thread to halt

    As a matter of interest is it really neccessary to make a copy of the bitmap contents? It might be more efficient just to copy it to a backscreen buffer context, make any chnages (which I assume you are doing) and then pass it over to the opengl environment.
    Download Symbian OS now! [url]http://developer.symbian.org[/url]

  15. #15
    Regular Contributor
    Join Date
    Jan 2005
    Posts
    154

    Re: Starting a thread that causes the main thread to halt

    Do you mean using MemCopy()? If you do, i chose to copy it manually because i want to do the processing on the image on the fly. in other words, whilst i am copying the bitmap data i am processing it in the same loop. I do not have to loop once to copy (which i suspect MemCopy does()) and once to process.
    If you mean something else then please calrify
    AF

Similar Threads

  1. S60 SDK 3rd edition FP1 Emulator problem
    By justteam in forum Symbian Tools & SDKs
    Replies: 14
    Last Post: 2010-03-23, 08:47
  2. emulator startup failed
    By hony in forum Symbian User Interface
    Replies: 3
    Last Post: 2008-11-11, 06:07
  3. error on "Emulator"
    By xmnlk in forum Symbian
    Replies: 3
    Last Post: 2008-05-22, 16:39
  4. ConnectionNotifier.acceptAndOpen() - lock a main phone thread?
    By fei_pisem_net in forum Mobile Java Networking & Messaging & Security
    Replies: 5
    Last Post: 2007-08-13, 15:26
  5. Can't start thread function
    By liuhoihing in forum Symbian
    Replies: 0
    Last Post: 2003-05-05, 06:35

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×