HiGHS Thread-safe?

[loehndorf]

Hi,

I am currently accessing HiGHS through the C interface from Java, and it generally works.

My application is multi-threaded, which means that I create highs solver objects in parallel.

When I use more than one thread I get the following messages: Strange: Solve time = 0.000175793; Sum times = 0.000117239: relative difference = 0.333085 when I have logging turned on, and Iteration total error 0 + 3 + 0 + 0 != 1 when I have logging turned off (runquiet).

To me, these message only makes sense when multiple threads have access to the same object, either the highs solver object itself or the HighsSimplexInfo. This makes me wonder if HiGHS is thread-safe.

Any ideas?

Thanks!

[jajhall]

Thanks for this. I understood that the way the solver had been written was thread-safe, and I know how important it is to people developing multi-threaded applications like you. I'll talk to those involved with HiGHS who would know what might have been done so that it's no longer thread-safe.

[loehndorf]

Thanks for the quick answer.

I did not encounter thread collisions when running the solver but only observed these oddities. My guess is that the same HighsSimplexInfo object is assigned to multiple HighsModelObject objects. This would lead to multiple threads writing the same stats.

[jajhall]

No, each HighsModelObject has its own HighsSimplexInfo. My only thought about the iteration count error report is that it involves static values - that I thought I'd heard were bad for thread safety. But I'm an algorithms person - the other three people in HiGHS are much more fluent in computer science!

I assume that your application is creating a different Highs instance - via calls so Highs_create(void) - for each LP that you're solving. If so, then you'll only have one HighsModelObject per Highs instance, other than during a call to Highs_run(highs).

[loehndorf]

Indeed. After making them non-static, the error messages disappear. I'll leave the issue open, because I suspect that there must be a reason for them to be made static in the first place. Anyways, thanks.

[tosttost]

HighsIO.cpp line 25-29 is also not thread safe - two solver running in parallel will mess up each others callbacks and in case both print messages at the same time strange things will happen due to the shared buffer.

[jajhall]

Thanks. These callbacks aren't used now in HiGHS - other than in a (redundant) unit test and the (broken) GAMS and OSI interfaces.

That said, we do want to introduce callbacks.

Parallelism in HiGHS is being revised completely at the moment - we've ditched OpenMP in favour of the C++ native parallelism - so it would be a good moment to re-write these callbacks. Could you do this, please @lgottwald ?

[lgottwald]

I'll have a look

[jajhall]

The static variables in HighsIO.cpp have been removed as a consequence of #709. There are some static variables associated with debugging methods that are not touched by default. Otherwise, the only classic static variables are used by the interior point solver and the QP solver.

[ghost]

I am currently accessing HiGHS through the C interface from Java, and it generally works.

Hi, would you be able to give a small example how you accessed HiGHS from Java?

[jajhall]

I don't think we ever did get around to calling HiGHS from Java, sorry

[tobiass-sdl]

I just saw

void HEkkPrimal::phase2UpdatePrimal(const bool initialise) {
  static double max_max_local_primal_infeasibility;
  static double max_max_ignored_violation;

which does not look like debug code. Is this only the parallel simplex or the default serial simplex? This piece of code is clearly not thread safe. Maybe those to variables can be promoted to fields of HEkkPrimal assuming that the values should not be reused by later instances of HEkkPrimal?

edit: bool HEkkPrimal::correctPrimal(const bool initialise) seems to be a similar case.

[jajhall]

These are only used to limit logging. However, they can easily be made data members of HEkkPrimal to avoid having global variables. This will contribute to #810

[tobiass-sdl]

Thanks. I ran (serial) primal and dual simplex, ipx and the mip solver in parallel on a bunch of mps files with the thread sanitizer enabled. I got no findings. While this not a proof that HiGHS is threadsafe - there might be false negatives in the sanitizer and/or uncovered code paths within HiGHS - I can't disproof it either and would assume that it is thread safe for now.

[jajhall]

That, this is really useful to know, as I wouldn't know how to test thread safety.