You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Non-exhaustive list of places where race conditions may occur
Class and method references are global variables in generated C bindings. These variables are checked during a call and looked up in JNI if they are null. Method/Field IDs do not seem to be problematic since they are not themselves reclaimable, and merely associated with the class reference. The class reference however may leak if 2 threads try to use an un-initialized class concurrently.
Is this a concern and does this operation (check-and-load-if-null) have to be wrapped in a mutex? I think something like double-checked locking can be used to retain a faster path in loaded case.
Spawn checks if the global JniContext is populated with non-null JVM reference. There's a chance if 2 spawns are called simultaneously. But spawn is supposed to be called at the beginning of the program. I don't think this is a significant concern.
The text was updated successfully, but these errors were encountered:
Non-exhaustive list of places where race conditions may occur
Is this a concern and does this operation (check-and-load-if-null) have to be wrapped in a mutex? I think something like double-checked locking can be used to retain a faster path in loaded case.
Spawn
checks if the globalJniContext
is populated with non-null JVM reference. There's a chance if 2 spawns are called simultaneously. But spawn is supposed to be called at the beginning of the program. I don't think this is a significant concern.The text was updated successfully, but these errors were encountered: