CmtGetLock Casuing one thread to Freeze

[Regenersis]

Hi.

I have a test system that tests two identical UUT's simultaneously using two threads of the same code. Within these two threads I require threadlocking so that a single hardware interface can be shared between the two units under test.

My problem is that occasionally (and randomly) either one of the threads seems to freeze at the CmtGetLock call and will not respond until the test software has been shut down and restarted. The other thread that doesn't freeze can carry on testing without a problem when the other one freezes.

The chopped down vesion of my code is something like below:

CmtNewLock ("Local\\UUT_IFDLL",OPT_TL_PROCESS_EVENTS_WHILE_WAITING, &gLockSTBinterfaceDll);

|

|

//blah blah blah

|

|

CmtGetLock (gLockSTBinterfaceDll);    //This is where one of either of the threads always freezes.

|

//use hardware interface

|

CmtReleaseLock (gLockSTBinterfaceDll);

|

//blah blah blah

|

Can anyone suggest a reason for this? Could it be an OS/PC problem?

Thanks.

  Neil.

[dummy_decoy · Accepted solution]

it sounds like a deadlock to me:

- thread A acquires the lock and, for whatever reason, forgets to release it.

- thread B waits for the lock which is not available since thread A did not release it.

- thread A can runundisturbed since it already has the lock, it can reacquire it any number of times it wishes.

- thread B waits forever...

are you absolutely certain that there is no early exit path between the acquisition and the release of the lock ? no way to NOT release the lock ?

i mean absolutely certain as in: no return, no break, no goto, no incomplete if...else..., no unbalanced braces, no possible software exception, nothing that breaks the flow of control...

[ebalci]

Hi Neil,

You can use the function CmtTryToGetLock instead of CmtGetLock to avoid the thread being unresponsive.

Note that this is not a solution for solving any problems previously mentioned by dummy_decoy.

Since CmtGetLock does not return until it gets the lock your code gets stuck at that line.

If you call CmtTryToGetLock in a loop where you call ProcessSystemEvents also, your thread will -at least- respond to your events so that you do not have to terminate your application.

Hope this helps. 

[Regenersis]

Thanks for the replies.

I have put debug code into my program and can see the thread lock being released successfully by the 'working thread' before the lock up occurs - I would expect the return of CmtReleaseLock to be non-zero if there was a problem??

Unfortunately, I'm using CVI8.0 and don't have access to the CmtTryToGetLock function.

Any other ideas?

Thanks.

[Regenersis]

Just to tie this off - I found a potential problem embedded in the code where a break in a case statement could jump out the loop without releasing the thread lock. Don't know if this has solved my issue completely yet, but I suspect it may well have.

Thanks for the replies - they were very useful.

Regards.

  Neil