LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CmtGetLock freezes on event val changed

Hi All,

I'm Using:
Labwindows CVI 7.0
Windows XP OS

I am having a problem with using threadlocking with CVI.

My code looks like the following:

****************************************************************************************
int myLock;

void main()
{
CmtNewThreadPool (1, &tPool);
CmtScheduleThreadPoolFunction (tPool, Thread, NULL, NULL);

CmtNewLock (NULL, OPT_TL_PROCESS_EVENTS_WHILE_WAITING, &myLock);
}

int CVICALLBACK do_Test (int panel, int control, int event,
void *callbackData, int eventData1, int eventData2)
{
switch (event)
{
case EVENT_VAL_CHANGED:
CmtGetLock (myLock);//application freezes here
CmtReleaseLock (myLock);
break;
}
return 0;
}
****************************************************************************************

The callback do_Test is hooked up to a numerical knob control. When I try to turn the numerical knob, on the first increment, I get an EVENT_VAL_CHANGED event. Then as soon as I step through the code to the "CmtGetLock (myLock)" line, the application locks up ( as if it already had a lock applied to it that was never released). In fact I can't use the stop button on the compiler either, I have to use the 'Terminate Execution' command to close my application. I have tried this with the dial having a range of 1-10 and 1-2000 and the same problem occurs. I have tried this with a numerical dial as well and experienced the same results.

Am I doing something wrong here? If not, is there a known workaround for this? Using a lock on EVENT_COMMIT works fine, but that is not an option, I need a lock on EVENT_VAL_CHANGED.
0 Kudos
Message 1 of 3
(3,363 Views)
Since you are processing events while waiting for the lock (because you passed OPT_TL_PROCESS_EVENTS_WHILE_WAITING) you end up with two EVENT_VAL_CHANGED events trying to acquire the same lock, which is bad. The first lock (which will eventually succeed) will never continue because the second lock is being called from the same thread and can never succeed. The simplest fix to this is to pass 0 instead of OPT_TL_PROCESS_EVENTS_WHILE_WAITING for that lock, which should resolve the issue.

Regards,

Alex
0 Kudos
Message 2 of 3
(3,358 Views)
Excellent, thanks Alex!
0 Kudos
Message 3 of 3
(3,354 Views)