Showing results for 
Search instead for 
Did you mean: 

Is this a Good multithread Lock implementation

Go to solution

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

Thread Lock.png

0 Kudos
Message 1 of 6

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.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 6

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 6
Accepted by topic author Onering20

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.

Message 4 of 6

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.

0 Kudos
Message 5 of 6

That's actually the general name. 🙂

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
0 Kudos
Message 6 of 6