LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Semaphore lifetime in delegate class

Solved!
Go to solution

Hi all,

Using LV2015 I've been experiencing some frustrating behavior involving semaphore references dying in a delegate class that contains the semaphore references in class data. I know that if the VI that created the semaphores leaves memory, the semaphore references leave with it. However, either I don't quite know what "leaving memory" means when it comes to LVOOP or there is some strange unintended behavior on display. 
In the attached example I call two classes directly from the top level. One class creates a semaphore reference and stores it in class data. Lets call it Semaphore Holder. The other class stores the first class in class data after the semaphore has been initialized. Lets call it Class Holder. When I try to get the status of the semaphore using the Class Holder I get Error 1, refnum not valid. However, if I get the status of the semaphore using the original Semaphore Holder class I get no error, even after the Class Holder has declared that the semaphore refnum isn't valid. Is there a way to store a delegate class that has already been initialized without losing references?

Thanks,

jppb

0 Kudos
Message 1 of 5
(2,927 Views)
Solution
Accepted by topic author jppb

The problem is in your "Write Semaphore Holder" method. You'll notice that the bundle is not actually updating the class output (try block diagram clean-up to see it). This is a common trap.

Message 2 of 5
(2,919 Views)

Shoot. Good catch tyk007, that will show me to write example code at the end of the day.

I was seeing exactly the problem I expected to, so I didn't look too closely at my example. However, this was not the issue with the original application that prompted this post. I can't post the original application online, but if I can create test code that mimics the behavoir I am seeing I will post a new example on this thread.

0 Kudos
Message 3 of 5
(2,879 Views)

Looking back at your more general question - there is no reason why the seamphore won't work how you think it should. A sempahore is just a queue in disguise anyway. Without forcibly deleting the semaphore the lifetime will be bound to the VI hierarchy that created it.

0 Kudos
Message 4 of 5
(2,875 Views)

You are absolutely correct. I have solved the problem in the original source code. Despite my conspiracy theorys, it was simply a case of data not getting where I thought it was going. Marking your above answer as solution.

0 Kudos
Message 5 of 5
(2,847 Views)