GE_SPINLOCK and Semaphore

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/05/2005 at 06:30, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   9.1
Platform:   Windows ;
Language(s) :     C++ ;

---------
Hello again,

in how far are those two different ?

UserArea and a Thread. The Thread ist continuously calculating stuff. And the UserArea must show this stuff. So in GeUserArea::Draw() i must synchronize with the thread and aquire data to be drawn.

Using a GE_SPINLOCK doesn't work. It looks as if the Draw functions get's mysteriously removed from the stack somewhere after calling GeSpinLock(), and so creating a deadlock because GeSpinUnlock get's never called.

Using a Semaphore does work flawlessly.

I was wondering why.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/05/2005 at 06:47, xxxxxxxx wrote:

Forget it, it must be my fault. It works in a simple testprogram.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/05/2005 at 09:15, xxxxxxxx wrote:

Ok i pinned it down to a call to GeDialog::SetTitle() in between GeSpinLock() and GeSpinUnlock()

maybe it's API bug.. if you change things in AsyncTest.cpp from the SDK Examples like this, then it will also freeze. And i see nothing that would be illegal.

  
//added  
class TestThread : public Thread  
{  
public:  
     virtual void Main()   
     {  
          someData = 0;  
  
          while( !TestBreak() )  
          {  
               GeSleep( 400 );  
  
               LockData();  
               for( LONG i=0; i<1000; ++i )  
               {  
                    ++someData;  
               }  
               UnlockData();  
          }  
     }  
     void LockData() { GeSpinLock( &lock; ); };  
     void UnlockData() { GeSpinUnlock( &lock; ); };  
     ULONG* GetData() { return &someData; };  
  
     GeUserArea *ua;  
     GE_SPINLOCK lock;       
private:  
     ULONG someData;       
};  
  
  
class SDKGradientArea : public GeUserArea  
{  
     public:  
          SDKGradientGadget ggtmp;  
          SDKGradient     grad[MAXGRADIENT];  
          LONG                    count,interpolation,type;  
            
          // added  
          TestThread thread;  
  
          SDKGradientArea(void);  
  
          virtual Bool Init(void);  
          virtual Bool GetMinSize(LONG &w;,LONG &h;);  
          virtual void Sized(LONG w,LONG h);  
          virtual void Draw(LONG x1,LONG y1,LONG x2,LONG y2);  
          virtual Bool InputEvent(const BaseContainer &msg;);            
};  
  
Bool SDKGradientArea::Init(void)  
{  
     ggtmp.Init(this,grad,&count;,&interpolation;,MAXGRADIENT);  
  
     // added  
     thread.ua = this;  
     thread.lock = 0;  
     thread.Start( TRUE, FALSE );  
  
     return TRUE;  
}  
  
  
void SDKGradientArea::Draw(LONG x1,LONG y1,LONG x2,LONG y2)  
{  
     if (!ggtmp.col) return;  
     LONG w = ggtmp.col->GetBw();  
     LONG h = ggtmp.col->GetBh();  
  
     // added  
     thread.LockData();  
     ULONG *data = thread.GetData();  
     GeDebugOut("data = %i",*data);  
     // this seems to cause a freeze  
     dlg->SetTitle( LongToString( *data ) );  
     thread.UnlockData();  
  
     DrawBitmap(ggtmp.col,0,0,w,h,0,0,w,h,0);  
}

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/05/2005 at 12:14, xxxxxxxx wrote:

I already posted this where you initially asked it. It is not permitted to call gui functionality in a threaded context. So this might also cover setting the title of a dialog. This is at least what the SDK documentation says. So it seems illegal.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/05/2005 at 03:12, xxxxxxxx wrote:

Hi

you know i have strong doubts that it is illegal because the Draw function seems to be executed in the main thread.

But i guess i will never know for sure...