Strange Semaphore Behavior

[theoneandonlyjim]

Some exposition before the question:

I'm trying to restrict access to a tool using semaphores.

In my top-level vi, I obtain the reference during my "Initialize" state and release it in my "Stop" state. The reference is untouched in any other state and resides in a shift register. When I pull the reference from the shift register, the "Release Reference" vi generates an error, saying the reference is invalid. I'm only to the point of testing my top-level VI, so no other manipulation occurs.

When instead I obtain the reference before my state machine loop begins (initializing the shift register), I don't get this error. I might be having a mental block, but it's not clear to me what the difference is between the two styles. What am I missing?

[Minh Pham]

Some exposition before the question:

I'm trying to restrict access to a tool using semaphores.

In my top-level vi, I obtain the reference during my "Initialize" state and release it in my "Stop" state. The reference is untouched in any other state and resides in a shift register. When I pull the reference from the shift register, the "Release Reference" vi generates an error, saying the reference is invalid. I'm only to the point of testing my top-level VI, so no other manipulation occurs.

When instead I obtain the reference before my state machine loop begins (initializing the shift register), I don't get this error. I might be having a mental block, but it's not clear to me what the difference is between the two styles. What am I missing?

would be easier if you can post a code snippet or example code of the problem.

Cheers

[ShaunR]

Some exposition before the question:

I'm trying to restrict access to a tool using semaphores.

In my top-level vi, I obtain the reference during my "Initialize" state and release it in my "Stop" state. The reference is untouched in any other state and resides in a shift register. When I pull the reference from the shift register, the "Release Reference" vi generates an error, saying the reference is invalid. I'm only to the point of testing my top-level VI, so no other manipulation occurs.

When instead I obtain the reference before my state machine loop begins (initializing the shift register), I don't get this error. I might be having a mental block, but it's not clear to me what the difference is between the two styles. What am I missing?

Check to make sure you have "wired through" the shift register. You will normally see this behaviour if there is a case selector with an unwired tunnel. If there is a case which has no wire connecting the left shift register node to the right node, that case will insert a "NULL" reference.

[crossrulz]

This might sound stupid, but are you sure you are running your "Initialize" state?

[theoneandonlyjim]

This might sound stupid, but are you sure you are running your "Initialize" state?

Not stupid at all. I was blinded by a long day and failed to see that I wasn't ever running "Initialize". Oof.

[Fab]

This sounded exactly like the problem I am having, unfortunately the solution mentioned above does not help me, the semaphore is being initialized

While running "Desktop Execution Trace Toolkit" in the code I am debugging, I realized that the semaphores used inside a FGV were returning error 1 after trying to acquire a semaphore and error 1111 after trying to release it.

I simplified the code to the bare bones to see if I could reproduce this problem.

Here is the odd behavior:

If I run the FGV with the single enum enabled and I run first "init" and then "acquire-release", I get "Error 1 occurred at Dequeue Element in Acquire Semaphore.vi"

If I enable the other case in the disable structure (an array of init, acquire-release, destroy) and single step through the code with highlighted execution there are no errors.

This might be basic knowledge regarding semaphores, but I don't understand why if the semaphore refnum is saved in the shift register, it is no longer valid the next time the VI is ran.

Please help me understand if this is valid behavior.

Thanks,

Fab

[Yair]

This has to do with the way LV handles resource cleanup.

When a hierarchy that a reference was created in goes idle (or out of memory), that reference is automatically destroyed.

So, in your case, the top level VI in the hierarchy is the FGV. You run it, the subVI creates the reference, then the FGV goes idle, so the reference is destroyed. You run it again and call the second case, but by now the reference no longer points to an existing resource.

In the second case it works because the FGV does not become idle.

[Fab]

This has to do with the way LV handles resource cleanup.

When a hierarchy that a reference was created in goes idle (or out of memory), that reference is automatically destroyed.

So, in your case, the top level VI in the hierarchy is the FGV. You run it, the subVI creates the reference, then the FGV goes idle, so the reference is destroyed. You run it again and call the second case, but by now the reference no longer points to an existing resource.

In the second case it works because the FGV does not become idle.

Yair,

Thanks, that makes sense. Now I need to see why when called inside the big application the FGV goes out of memory.

Fab

[Yair]

The same concept should apply. The hierarchy is determined by the top level VI (that is a VI you run yourself or using the Run VI method with the appropriate flag). If the TLV under which the init case is called goes out of memory, the reference will be destroyed.