Jump to content

Strange Semaphore Behavior


Recommended Posts

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?

Link to comment

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

Link to comment

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.

Link to comment
  • 4 months later...

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

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.

post-17236-083341400 1284485033_thumb.pn

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

Link to comment

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.

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.