AnsweredAssumed Answered

Problem when Creating/Destroying Mutex/Semaphores in VDK Thread Constructor/Destructor

Question asked by DampSquid on Jun 6, 2013
Latest reply on Jun 28, 2013 by JamesH

Whilst developing my server IP socket classes using lwip I came accross a problem with VDK::DestroyMutex being called within a VDK::Thread destructor.


Initially I created a VDKMutex Class to simply wrap the VDK:: calls and hide the MutexID.  This class was then included in the VDK::Thread derived class and as such in automatically created and destroyed with the Thread class.


After the VDK::DestroyMutex is called in my app everythig appears to hang, the Statistical profiller shows that nrealy all the processing is now in the IdleThread.  Halting the application and looking at the VDK status, all thread are show as Blocked, most on Semaphores but one also on a Message,  alot of these are Blocked with timeout and all timeouts have expired.


I've managed to reproduce the issue with a much simple example from the Getting started.


I'm using the EZ-Kit BF548


Open the Getting Started Example_7 ( keypad to led example )

Create a new thread type named Boom using in C


At top of new thread file Add global variable

VDK_MutexID mID;

in Boom_RunFunction remove the while loop so the thread simple creates the dies on completion of Run

in Boom_InitFunction add

mID = VDK_CreateMutex();

in Boom_DestroyFunction add

VDK_DestroyMutex( mID );


In BootThreadType add

if( type == 0x0003 )


     VDK_CreateThread( kBoom );


after the

int type = ((keypress.row << 8) | keypress.col);


Run the application

pressing any keypad other than CLEAR will show the ROW/COL as expected on the LEDS.

Once CLEAR is pressed the application still runs (no kernel panic / or other halt error) but the only Thread Operating is the IdleThread.


Does anyone have any idea why this behaviour appear to hang any Pend call in the VDK ??


I know I'll have to refactor the code to put everything in the RunFunction but I'm interested as to whats happening here.