Potential scriptengine deadlock

1

this message is related to this topic

and I want to seperate this discussion a bit, to avoid Hijacking the original discussion thread.

you are right. Thats new and will be released with openhab > 5.1 M1.

@florian-h05 I would guess that this will result in a deadlock. Except we remove the extra lock in beforeInvocation / afterInvocation, in javascripting and pythonscripting.

Currently we lock with the surrounding logic and additionally we try to lock again, as part of eval where we try to lock again.

But if we remove the lock inside eval, we have the risk that somewhere the eval is used without locking the engine first.

e.g. in the transformation service. This is not 100% a problem, because there is a separate lock, but still not the engine lock.

2

@rlkoshak Is there anything “wrong” with this topic - I can’t seem to be able to subscribe to it..?

edit: After I posted this comment, the “subscribe button” showed up.

1 Like
3

Why should it??

4

the engine lock function is using the same lock object as the beforeInvocation function

means the following steps happens

  1. .lock() is called and aquires the lock
  2. .eval() is called which triggers .beforeInvocation() which tries to aquire the lock again

maybe I’m thinking wrong here.

5

There’s a hint in the name of the implementation:

    private final Lock lock = new ReentrantLock();

You can reenter locks as many times as you want in Java, I don’t think a non-reentrant lock implementations actually exists. It is “counted”, so the lock isn’t released until it has been unlocked the same number of times as it has been locked.

1 Like
6

OK, I misunderstood

@florian-h05 so just ignore this discussion :innocent:

2 Likes
7

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.