LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is this a Good multithread Lock implementation

Solved!
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
(262 Views)

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.


GCentral
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
(257 Views)

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
(245 Views)
Solution
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
(200 Views)

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
(165 Views)

That's actually the general name. 🙂

https://en.wikipedia.org/wiki/Semaphore_(programming)

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 6
(109 Views)