09-28-2022 10:41 AM
I have a process that communicates to a unit and expects a response and I am looking into multithread locks to prevent communications from getting mixed.
Is using channels like this a good approach for doing that or is there a best practice that I could be using
Solved! Go to Solution.
09-28-2022 10:50 AM
A simple Semaphore would do what you are showing. I think I would feel more inclined to use a DVR of a class and then use the In Place Element Structure as the mutex.
09-28-2022 11:08 AM
Not sure what your app's "big picture" is, but another *potential* alternative that might fit:
Don't distribute access to the communication channel to different parts of your code that can want simultaneous access to this piece of equipment. Instead, confine all your communications to a code module that's something like a state machine or message handler. Maybe even a simple Action Engine could be used to mediate access without having to manually manage semaphores and the like.
-Kevin P
09-28-2022 12:21 PM - edited 09-28-2022 12:25 PM
I would say that no, that isn't a good lock implementation. The reason for that is that after a given While loop finishing (to indicate that the resource is "open") there is a chance a parallel thread will also see that it's "open" and both will write a "True" value to the lock channel and then start executing its code as well.
As mentioned earlier, a Semaphore is much more along the lines of what you should use here. While there are alternatives, whichever one you use needs to make sure that the "check to see if it's open" function simultaneously is also a "lock it if it's open" function so that you never have a potential race condition.
09-28-2022 01:36 PM
Thanks for the information, not that the LabVIEW naming convention is wrong, but I did not put together that 'Semaphore' was the name for train signals and Thread control in LV.
09-29-2022 10:04 AM
That's actually the general name. 🙂