LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

semaphorize?

Dear all,

I need some help from those who have experience in automation. Perhaps,
the problem does not really belong to Labview, rather C++, but...
So. I have a .dll acts an automation server, the Labview is the client.
The .dll performs operation on a specific hw. Everything works well if
only one vi is runnning. The vi calls the activex methods as usual.
The problem is the case when more than one vi are running
simultaneously. They use the same .dll, so far no problem, but they use
the same/shared hw resource through it. To protect the access and what
could resolve this case is the sychronisation. e.g.: semaphores. The
solutions would be simple if I wouldn't have at least a hundred methods
in the .dll. Those shouldn't be run parallel, consequently every one of
them should be protected by a common semaphore.
Modifying on both the Labview and C++ side seem to be "simple", but not
too elegant: to each method I should add semaphore operations or ...
Is there a common entry in the .dll before the called activex methods
start to run or ...
Well, have got any idea?

Many thanks advance
0 Kudos
Message 1 of 4
(2,317 Views)
You should write an ActiveX handler.  The input to this code would be the ActiveX method to be called.  The code would check the semaphore to see if it is allright to call the ActiveX method.  If semaphore is unlocked, simply call the method.  If locked, do not call the method and return some kind of code to signify that the method was not called.  You could even build in a queue of some sort that would stack the callers in order and call the methods when the caller's turn is next on the queue.
- tbob

Inventor of the WORM Global
Message 2 of 4
(2,315 Views)
That's a great idea tbob. If you used one non-reentrant subVI that contained a Case Structure with all the possible ActiveX calls and an enum to decide which to call (OK, maybe that's unrealistic or prohibitive), then you wouldn't even need a semaphore. That non-reentrant subVI could only be called from one location at a time, thus protecting access to your HW.
Jarrod S.
National Instruments
Message 3 of 4
(2,307 Views)

I second the suggestion by Jarrod!

I originally learned about that technique from Greg McKaskle as a way to prevent simultaneous calls to thread safe dll's.

I usually don't rate the answers from "Blue Bars" but I think Jarrod has earned these.

Ben

PS: No I am not looking over your shoulder. Smiley Wink

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 4
(2,296 Views)