Const correctness and thread safety in the C-API

Hi Bo,

in general our internal btran/ftran functions are thread-safe and are already called from multiple threads during our parallel dual/crossover. Unfortunately, it appears that the XPRSbtran and XPRSftran functions are not due to the way the provided solution is stored before calling the actual btran/ftran, but if this would be important for you, it should be possible to add new functions for this that would be thread-safe.

Any specific functions you are wondering about with regards to the const? In general most of the get functions should normally leave the XPRSprob unchanged, while the solve functions as well as any add/set functions would not, but if you are wondering about any specific ones, I can double check in the code.

Strictly speaking there is also the issue that even the get-methods might store the last error code within the XPRSprob if the input arguments were incorrect so that it can be checked via XPRSgetlasterror, so in that regard pretty much no function could be considered truly "const".

Best,

Tristan

Hi Tristan,

Thank you for the clarification. I would have expected a set of functions to be marked as const by having a XPRSConstprob definition as input for these cases. That's why I asked.

I will work with what we have then :-)

Hi Bo,

note that a prob does not only describe the problem to be solved. It also describes the environment/context in which the problem is solved. In particular, it carries the last error code and last error message (see XPRSgetlaserror, for example). Since this may change for any XPRS function, the prob itself can never be const.

Once could probably introduce a notion of "conceptually constant" but that would not be very clear cut and would also not be something that one would enforce by using the `const` keyword.