Can Sys.Lock[i] cause deadlocks?

[teaguehall]

I was searching for mutex lock support in the PMAC Script Language and stumbled across the Sys.Lock[i] variable in the user's manual. 

Per the "Power PMAC User’s Manual" version published May 15, 2019, it builds a case for the use of Sys.Lock[i] as a way to avoid incorrect register writes when two tasks occur concurrently operating at different priority levels (i.e. background PLC vs realtime PLC). In general, the example in the manual makes sense and appears to be working using some cursory tests.

However, I'm trying to determine if there's a risk of deadlocks when tasks running at different priorities reference the same Sys.Lock[i]. Here would be the scenario:

1. Background PLC successfully obtains Sys.Lock[1] and begins running critical section.

2. While Background PLC is in possession of lock, Realtime PLC interrupts and attempts to grab Sys.Lock[1]

3. The Realtime PLC uses the convention "while (Sys.Lock[7] == 1) {} " and spins while waiting for the lock to be available.

4. Because the Realtime PLC is stuck in a loop waiting, the Background PLC never gets enough time to finish the critical section and release the lock.

5. We're now stuck in deadlock where Realtime PLC is waiting on Background PLC to finish, but Background PLC is waiting for Realtime PLC to finish since it's at a higher priority.

 

Is this a valid scenario/concern? I guess I'm hoping it's not, but it seems like it would be based on my understanding on how tasks are scheduled on the PMAC. Any clarification would be appreciated!

 

 

[steve.milici]

I don’t think the “Process Locking” feature is your issue. With the suggested usage of the Sys.Lock[] element, the “clearing” of the lock would be within a few scans of the PLC.

My educated guess is something else in the PLC is “holding” up the execution.

Contact ODT's direct technical support with your full issue details at: ODT-Support@Omron.com

[steve.milici]

Also note there are updated versions of the Power PMAC manuals:

https://assets.omron.com/m/76e3f5e50c46e0e9/original/Power-PMAC-Software-Reference-Manual.pdf

https://assets.omron.com/m/2c1a63d391d6bfa3/original/Power-PMAC-Users-Manual.pdf

 

[teaguehall]

Hi Steve, thanks for sharing the updated manuals.

I'm actually not experiencing any lock-ups currently, I'm just curious if the scenario I describe would put my application at risk. Essentially - if a realtime PLC were to get stuck in a loop waiting for a lock to be released, would a background PLC in possession of the lock be able to progress and release the lock? or would the realtime PLC starve all available resources?

[steve.milici]

Any PLC inside an “active” while loop would not starve any resources. The remainder of “that” PLC will not execute but after each while “scan” the PLC will release time to the next PLC in priority order.