Need help with semaphore waiting for each other.

[Thang Nguyen 2]

First of all I have to say that I posted this question on NI forum, but I still don't have a solution yet, so I hope you can help me.

I have a case with semaphore vis getting stuck (deadlock) waiting for each other.

In my program, I have 2 dynamic VIs.

The first one, called processtransmit.vi, sends continously messages to CAN at different rate. So I used parallel time-loops with different interval times. Each of these loops has a semaphore to guarantie that there is only one loop can call send data function to send message to CAN at a time.

The second one, called processreceive.vi, receives messages from CAN. If there is a request message it will send back some asynchronous message. Cause it also using send CAN function so I also use semaphore.

After runing for couple of seconds, all of these semaphores get stuck. I did try turn on the hight light function both before and after it gets stuck but I still not understand why this happens.

I attach here 2 pictures, one is processtransmit.vi, another one is responsemessage.vi which is call from processreceive.vi. You can see the waiting green arror on the acquire semaphore VI. The response VI will be send out base on the request message.

I would appreciate any helps or suggestion of another architect which make it runs better.

Best regards,

Thang Nguyen

[crossrulz]

If all CAN transmits have to go through a single VI, simply make that VI non-reentrant and the semaphores aren't needed. The VI itself will act like a semaphore since it can only run in one thread at a time. I did the same thing with a serial port until I made the realization that they aren't needed due to the non-reentrancy of my serial port control VI.

But I seriously wonder what is holding your semaphore.

[Francois Normandin]

After runing for couple of seconds, all of these semaphores get stuck. I did try turn on the hight light function both before and after it gets stuck but I still not understand why this happens.

Hello Thang,

Is there a reason you put the unlock semaphore inside the False loop? I notice you don't have wired the timeout input so it will always be the false case that runs, but it could play trick on you down the road if you ever change that.

And that might be a very basic advice, but if your program hangs after 5 seconds, look at the CAN VI (CAB5S Process) in loop 1... If one of your subvi doesn't go through, you will never release the semaphore. To see if that might be the case, wire a long timeout and see if the other loops continue or stall.

[Thang Nguyen 2]

Hello Thang,

Is there a reason you put the unlock semaphore inside the False loop? I notice you don't have wired the timeout input so it will always be the false case that runs, but it could play trick on you down the road if you ever change that.

And that might be a very basic advice, but if your program hangs after 5 seconds, look at the CAN VI (CAB5S Process) in loop 1... If one of your subvi doesn't go through, you will never release the semaphore. To see if that might be the case, wire a long timeout and see if the other loops continue or stall.

I use unlock semaphore to release the semaphore after it finish sending out message. I have a flag to control whether the system reponse the request message or not. In that case, my processtransmit.vi runs really well. I did use this same architecture for my another project and it runs smoothly for almost a year now. The only different is in the response VI, I don't use release semaphore VI. Then I thought that I should use semaphore to keep them in the same fashion. Then now it stucks.

I didn't use time out because I want to keep my message send out at the right interval time, cause this software interacts with another realtime system. If it miss one loop the system will go to false state.

I did check that the response VI does work for couple of seconds and then all of them get stuck.

Thank for your concerns.

@Crossrulz:

I think maybe I should try this. But is it waste when NI create all of these semaphore VIs?

Edited August 3, 2009 by Thang Nguyen 2

[Thang Nguyen 2]

I just remove all of the acquire semaphore and release semaphore VI in my response message VIs and it works now. It's kind of the random response create the traffic jam. But I still not understand why this happen here. Isn't it right that there should be one can acquire the semaphore?

[Rolf Kalbermatter]

I just remove all of the acquire semaphore and release semaphore VI in my response message VIs and it works now. It's kind of the random response create the traffic jam. But I still not understand why this happen here. Isn't it right that there should be one can acquire the semaphore?

What version of LabVIEW is that in? Any chance that your CAN VIs return an error in the error cluster sometimes? The Release Semaphore Vi in versions prior to LabVIEW 8.6 did only execute when no error in was passed to it.

Rolf Kalbermatter