Please add some documentation describing the thread safety disposition of key types

[acmorrow]

It is entirely possible I've gone looking in the wrong places, but I have yet to find any documentation or header comments that explain the thread safety disposition of key types like class URDriver or class RTDEClient.

This leaves me unsure about whether I can freely share access to instances of these types these across threads without additional locking, or if I need to synchronize access to instances of these classes myself, or even ensure that access is limited to a single owning thread, etc.

I realize there is a lot of surface area to cover given that it is a layered API, but maybe a brief paragraph in each of https://github.com/UniversalRobots/Universal_Robots_Client_Library/blob/master/doc/architecture/ur_driver.rst and https://github.com/UniversalRobots/Universal_Robots_Client_Library/blob/master/doc/architecture/dashboard_client.rst giving a rough description of the intended/permitted concurrency semantics would go a long way towards clarifying the situation.

[urfeex]

That is something I'll have to think about first, which matches your experience. I'm not sure how much sense it would make to comment this on a class level as possible conflicts would probably rise from individual methods only.

Is there anything particular I can help with ad-hoc to get you unblocked?

[acmorrow]

Thanks for getting back to me. I understand it can be challenging to backfill this sort of documentation if the answer isn't currently known, as it can take a lot of research.

What prompted my question is that I'm looking at some code that uses a high frequency background loop to do most of the communication with the arm via UrDriver and DashboardClient. But there are a few places where it looks to me like there is unsynchronized access to these objects from another thread. I was hoping to get an answer that would let me conclude whether or not this was known safe (I suspect it is not).

I think, given your reply, that the correct thing to do here is to take the conservative position and assume that concurrent access should be prohibited, and ensure that all interaction with instances of these types is isolated in the one thread.

I guess one follow-up question would be this: if I take the conservative approach and ensure that access to the URCL driver and dashboard types is kept to a dedicated thread, is it safe to have more than one instance? For example, if I have two arms I'm trying to control from the same process, is it OK to have two worker threads, each with their own UrDriver and DashboardClient? I think that should be an easier question to answer, because it should amount to whether or not the library makes use of any global mutable state shared across those types or their internals. I'm hoping the answer is "no".

Finally, I have some other questions along these lines. Is sharing them with you via GH issues your preferred channel for these types of inquiries? Or is there another venue (discord, etc.) that you would prefer?

[urfeex]

I was hoping to get an answer that would let me conclude whether or not this was known safe (I suspect it is not).

Since this library basically was extracted from a specific application at some point (The ROS driver). As I wrote, thread safety isn't necessarily considered everywhere. At some parts it is. For example, the RTDEWriter class should be thread-safe to use. But yes, it's better to be conservative about this in general.

I guess one follow-up question would be this: if I take the conservative approach and ensure that access to the URCL driver and dashboard types is kept to a dedicated thread, is it safe to have more than one instance? For example, if I have two arms I'm trying to control from the same process, is it OK to have two worker threads, each with their own UrDriver and DashboardClient? I think that should be an easier question to answer, because it should amount to whether or not the library makes use of any global mutable state shared across those types or their internals. I'm hoping the answer is "no".

Yes, you can have two instances being connected to different robots without any issues. However, you'll have to configure different port numbers for one of the UrDriver instances (reverse port, script sender port, etc.).

Finally, I have some other questions along these lines. Is sharing them with you via GH issues your preferred channel for these types of inquiries? Or is there another venue (discord, etc.) that you would prefer?

Yes, GH is the channel that I'm monitoring the most.

[acmorrow]

I was hoping to get an answer that would let me conclude whether or not this was known safe (I suspect it is not).

Since this library basically was extracted from a specific application at some point (The ROS driver). As I wrote, thread safety isn't necessarily considered everywhere. At some parts it is. For example, the RTDEWriter class should be thread-safe to use. But yes, it's better to be conservative about this in general.

Thanks for confirming. A few sentences along those lines somewhere in the documentation wouldn't hurt.

I guess one follow-up question would be this: if I take the conservative approach and ensure that access to the URCL driver and dashboard types is kept to a dedicated thread, is it safe to have more than one instance? For example, if I have two arms I'm trying to control from the same process, is it OK to have two worker threads, each with their own UrDriver and DashboardClient? I think that should be an easier question to answer, because it should amount to whether or not the library makes use of any global mutable state shared across those types or their internals. I'm hoping the answer is "no".

Yes, you can have two instances being connected to different robots without any issues. However, you'll have to configure different port numbers for one of the UrDriver instances (reverse port, script sender port, etc.).

Yes, understood about the ports.