I am using the thread safe variable macros in the LabWindows/CVI environment and have observed that it is possible to get a pointer to a thread safe variable before it has been released. (from a previous request)
Because the data I am interesting in protecting is a struct
, I am unable to explicitly set nesting level, so I assume that the nesting level stays at 0, i.e. that once a single thread safe pointer has been issued, a request for second will be denied until the first has been released. However, I have observed this not to be true while stepping through a debug session. Execution continues through the DefineThreadSafeVar(CLI, SafeCli);
statement by continuing to use the F8 step-into key, and subsequent requests for a pointer to the thread-safe variable are granted without ever having released the original.
My expectations are that these macros should prevent access to a thread-safe variable once a pointer to it has been issued and not yet released.
Are my expectations incorrect?
Or have I implemented the calls incorrectly?
Here is my source code:
#include <utility.h>
typedef struct {
int hndl;
int connect;
int sock;
}CLI;
DefineThreadSafeVar(CLI, SafeCli);
void func1(void);
void func2(void);
int main(void)
{
InitializeSafeCli();
func1();
return 0;
}
void func1(void)
{
CLI *safe;
safe = GetPointerToSafeCli();//original issue
safe->connect = 2;
safe->hndl = 3;
safe->sock = 4;
func2();
safe->connect;
safe->hndl;
safe->sock;
ReleasePointerToSafeCli();
}
void func2(void)
{
CLI *safe;
safe = GetPointerToSafeCli();//request is granted. previous issue had not been released.
//shouldn't request have been denied ?
safe->connect = 5;//variable is modified.
safe->hndl = 6;
safe->sock = 7;
}