Quote:
Originally Posted by Greg McKaskle
I was asking for several reasons. From the manual ... "If you use this VI to obtain multiple references to the same named semaphore, each reference number is unique. "
So it is saying that each obtain should be balanced with a close. If it isn't, you wind up with quite a few refnums in short order.
I also ask, because the semaphore is often not the right tool for the job. They are a rather dangerous way to protect compared to the critical section that is built into every subVI. So the recommended way to protect a global is simply to wrap it in a function that is not reentrant. This critical section is considerably safer as it cannot be mismatched. The semaphore is only needed when the acquire and release are far removed from each other.
Greg McKaskle
|
I see what you're saying, I hadn't picked up on that nuance of the semaphore functionality. That entirely explains the issue we were observing. Since we scaled back to only the semaphore acquire on loop entry, we see no issue any longer anyways, but its certainly better to understand exactly whats going on than leave any ambiguity.
On the topic of methods of handling critical sections, I agree, more recently we've been using functional global variables to implement class like structures, but the concepts involved I find more difficult to explain to students than semaphores. Tasking is a deep enough topic as is to explain to high school aged kids, and I find semaphores a better introduction to the concepts of mutual exclusivity (especially for not -just labview- purposes) than diving straight into non reentrant functions.