Hi Alison. Access to global variables from the Java side of the fence can be made thread-safe, by adding the required synchronization. Note that a global variable is a memory segment, and memory segments support memory fencing and and atomic access (e.g. CAS). But, if the library is not thread-safe, the problem will always be that if you have many Java threads each doing their own downcalls to the native library, you are breaking the library invariant. So now it could be that there is some C/C++ code (the library code that you don't control) that could be making unsafe, non-fenced/atomic access to global state. And then you'd have a problem. Depending on how the library is, you might get away with different styles - e.g. you could pass a lambda expression to a method with some "actions" to be performed on a "device client". The method would create a device client, then pass it to the lambda, then "close" the device client immediately afterwards. If access to this lambda-accepting method is serialized (e.g. only one client at a time can ask for this, others have to wait), then the library might be safe again. But it really depends on the contract enforced by the library you are using. I'm sorry I can't be more specific. I hope the above somehow make sense :-) Regards Maurizio On 21/08/2024 16:52, Alison Gravley wrote:

I have a C library that isn't thread safe due to globals. Normally this would result in us running multiple applications for each instance we needed, but wondered if there was a another way to achieve this. I might even be wrong, and due to the way we wrote things it will work anyway.

To provide a little bit of context we wrote a Java library, call it Device Client Library, that uses this C library to make a single connection. In your application, you create a Device Client object for each connection you need to make. My understanding is this still doesn't give the separated memory space needed for the globals or do the right kind of operating system calls to allow this to work the same way multiple running applications would.

Is this correct? Is there maybe something we could modify in the Runtime Helper to get around this limitation so we don't have to have 30-40 applications running?