-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thread safety problem in predict: flag_predict_probability shouldn't be static #38
Comments
Thanks for the bug report. I can see the thread-safety problem. It exists since the beginning and from my understanding also in predict.c of the original C++ implementation. Have you already reported an issue in https://github.com/cjlin1/liblinear? This concurrency bug was probably not discovered so far because the more usual way to run predictions programmatically is to call |
Unfortunately the workaround to directly call Linear.predict() isn't usable for us, as we're using an additional abstraction layer that can use either the separate liblinear-train / liblinear-predict native binaries (out-of-process), or liblinear-java if the native versions aren't available. Configuration for training and prediction is given in a config file in the form of a string representing the LibLinear command line, which needs to be parsed identically by both the Java and the native versions. The command line parsing function in liblinear-java is private, and even if it weren't, it uses the same static variable as main() (as well as calling System.exit(), which shoots down the caller on error, rather than throwing an exception or returning some invalid value). This is not an issue in the C++ version, as that can never be loaded in-process as a library, but only executed as a separate process. |
This change is now released via version |
The flag_predict_probability boolean in predict is declared static. This causes a problem when running 2 different predict jobs in the same Java process with different probability options: the setting from the second call will overwrite the one from the first call. This may cause a prediction using a non-probabilty-capable solver type to fail, despite being called with correct parameters, if a simultaneous job runs with probabilities enabled.
The text was updated successfully, but these errors were encountered: