Handling non-thread safe libraries due to globals

[Maurizio Cimadamore]

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?
>