search

ChimeraTK / ControlSystemAdapter

An adapter layer which allows to use control applications with different control system software environments.
GNU Lesser General Public License v3.0
3 stars 2 forks source link

Writing persist files blocks control system adapter #21

Closed zenker closed 4 years ago

zenker commented 4 years ago

I just tested an application using the latest ControlsystemAdapter. I saw that my LabView client panels got stuck periodically. This is related to writing the persist file. I checked this by changing the persist file writing period.

By removing the following lock: https://github.com/ChimeraTK/ControlSystemAdapter/blob/b2bd4a34488dc8af6da36398fac707a9c232a440/include/ChimeraTK/ControlSystemAdapter/PersistentDataStorage.h#L139 and removing related lock calls the client application was no longer affected by persist file write actions.

I did not yet invest how the client can be affected by writing the persist file and using that lock.

mhier commented 4 years ago

I think the problem is the corresponding use in teh lock in PersistentDataStorage::writerThreadFunction(), because there it can be held for a long time. Can you try moving it into PersistentDataStorage::generateXmlValueTags()?

zenker commented 4 years ago

Now the client is not blocked as long as before. But still it is blocked. Isn't the file writing running in a separate thread. So the thread running the OPC-UA server in my case should not be affected?

The current situation (after applying your supposed changes) is not acceptable... For reference I will push a branch with my changes.

zenker commented 4 years ago

...if you grant me access rights.

mhier commented 4 years ago

We have to synchronise the data transfer between the control system thread (which posesses the data) and the file-writer thread. At the time I thought using a short lock should be acceptable here, so we can avoid a complicated lock-free mechanism (which also has downsides performance-wise, as it requires a lot more data copies).

I still think it should be possible to solve this situation by making the lock as short as possible. So far (in the current master) the lock is held for the entire duration of collecting the data, generating the XML code and writing it to disk. The lock should only be necessary while accessing the actual data, once it's copied out we can release it.

mhier commented 4 years ago

...if you grant me access rights.

invitation sent