Using a semaphore lock correctly

[Omar Mussa]

Yesterday I spent a few hours chasing down a memory leak in some code. It reminded me of a few things:

1) The value of reusable code (this VI should have been a reusable VI)

2) The value of unit testing (I wasn't unit testing)

3) The value of running long/overnight tests (until we ran the burn-in overnight test we didn't catch this problem).

Basically, I was using a semaphore as a lock to some hardware resources. I accidentally used the wrong check for 'Not A Refnum' which results in creating a new semaphore every time the code executes.

Here is the correct way that fixes the leak:

Hopefully this helps someone avoid a few hours of debugging a memory leak that shouldn't exist in the first place!

It would be nice if the 'Not a Refnum' primitive could do some kind of internal casting and checking so that both VIs would work -- but at least I won't be making this mistake again (and since I'm adding it to our company's reuse pool, hopefully nobody else will either!).

[Val Brown]

QUOTE (Omar Mussa @ Nov 21 2008, 10:09 AM)

It would be nice if the 'Not a Refnum' primitive could do some kind of internal casting and checking so that both VIs would work -- but at least I won't be making this mistake again (and since I'm adding it to our company's reuse pool, hopefully nobody else will either!).

Good catch! And, yes, it would be nice if that primitive could catch "not a semaphore refnum either".

[Francois Normandin]

Thanks Omar, :thumbup:

I think I have something similar. (I have a server that ran for three months non-stop and I got to 1.5GB virtual memory usage... pretty sluggish)

I'm almost sure I check for a semaphore with "Not a refnum".

[Jim Kring]

Omar,

Thanks for sharing your story with us. This is certainly one of those "Why did LabVIEW let me make this mistake?" scenarios, and every LabVIEW user will eventually make this mistake a dozen times over the course of a long career.

It should also be noted that this affects any of the non-native by-reference "objects", such as: (classic) notifiers, semaphores, rendezvous, configuration files, (classic) queues, etc.

[Neville D]

QUOTE (Jim Kring @ Nov 21 2008, 02:19 PM)

It should also be noted that this affects any of the non-native by-reference "objects", such as: (classic) notifiers, semaphores, rendezvous, configuration files, (classic) queues, etc.

Hopefully, by now most people have moved away from the classic non-native Q's and notifiers, so they are less likely to be bitten by this. These VI's have been replaced by native function calls that don't exhibit this behaviour since atleast LV 7x?

It would be nice if NI cleaned up the remaining categories still affected namely: Semaphores, rendezvous and config files.

<nudge> <nudge> AQ are you listening?

Neville.

[Jim Kring]

QUOTE (Neville D @ Nov 21 2008, 03:07 PM)

Hopefully, by now most people have moved away from the classic non-native Q's and notifiers, so they are less likely to be bitten by this. These VI's have been replaced by native function calls that don't exhibit this behaviour since atleast LV 7x?

It would be nice if NI cleaned up the remaining categories still affected namely: Semaphores, rendezvous and config files.

<nudge> <nudge> AQ are you listening?

Neville.

Or, how about native semaphores that can also store a single data element and that allow us to specify inheritance of the semaphore reference type

[Dean Mills]

In case no one has looked inside the semaphore VIs. The semaphore is just a wrapper for a queue. I haven't looked inside it for many years (LV6 likely) but the not a refnum got me thinking, what is it inside. The rendezvous VI's are also just a wrapper for a queue.

Dean

[Jim Kring]

QUOTE (Dean Mills @ Nov 21 2008, 04:32 PM)

In case no one has looked inside the semaphore VIs. The semaphore is just a wrapper for a queue. I haven't looked inside it for many years (LV6 likely) but the not a refnum got me thinking, what is it inside. The rendezvous VI's are also just a wrapper for a queue.

Same with the classic (compatibility) queue VIs.

[Yair]

QUOTE (Dean Mills @ Nov 22 2008, 02:32 AM)

The semaphore is just a wrapper for a queue.

But this is new. I believe it was only changed in 8.6 and was implemented using CIN calls until now.