open62541: fix race condition

[dirk-zimoch]

The scope of opslock was too small in processRequests(). It would need to overlap with the scope of clientlock but that could lead to deadlock. Solution: use only clientlock with large enough scope and drop opslock.

[ralphlange]

Are you sure you can drop the opslock?

The 'outstanding operations' map is being used by multiple independent threads: EPICS threads that can add operations and either low-level driver threads (incoming data) or timer threads (timeouts) that remove them.
If that is the case, the map needs to be protected.

The deadlock argument is only true if both sides take both locks in different order. For that, the code under the opslock would have to take the clientlock.

[dirk-zimoch]

Always when opslock would have been taken, clientlock is taken as well. In particular, the session workerThread loop keeps clientlock except while it is waiting for events. Thus, all callbacks (readComplete, writeComplete) are run with clientlock hold. processRequests takes clientlock before checking isConnected, so that connection status cannot change (and most important client cannot become invalid) before sending the request.

[ralphlange]

That's the architectural difference between the two low-level drivers that I was unsure about.
Fine, then!

[dirk-zimoch]

See also the comments on clientlock in the workerThread's run() function.