Feature: Multithreading for Alarms & Conditions

[basyskom-jvoe]

When I attempt to trigger an event from inside activateSession(), the application is terminated due to the assertion in the UA_LOCK macro. The counter variable is already 1 at that point because UA_LOCK was already called in processMSGDecoded().

As the call is coming from the thread already holding the lock, shouldn't it be legal to acquire the lock again?

Please provide the following information:

• open62541 Version (release number or git tag): v1.2.2
• Other OPC UA SDKs used (client or server):
• Operating system: Windows 10, MSVC 2013
• Logs (with UA_LOGLEVEL set as low as necessary) attached
• Wireshark network dump attached
• Self-contained code example attached
• Critical issue

[basyskom-jvoe]

I can also trigger the locking asserts in the following scenario:

• Enable Alarms & Conditions, set UA_MULTITHREADING to 100
• The main thread runs UA_Server_run()
• A second thread creates conditions
• A client (e.g. UaExpert) calls ConditionRefresh

There are several places in the code where a function calls UA_UNLOCK() before calling some other function and then calls UA_LOCK() again after this function has returned. My guess is that the second thread could use one of these situations to sneak a lock in.

[jpfr]

The problem in ActivateSession is fixed in #4609.
The Alarms&Conditions API currently does not have the UA_THREADSAFE tag.
So it makes no assurances being thread-safe.
We will refactor the locking behavior once we get there.

[jpfr]

Adjusted the title as a reminder that A&C Multithreading is not yet done,

[xujiesh0510]

Adjusted the title as a reminder that A&C Multithreading is not yet done,

ConditionRefresh is good in master branch version. but confirm alarm、acknowledge alarm、 add comment still not ok