search

jonls / qsopt-ex

QSopt_ex - an exact linear programming solver. This is a fork adding improvements to the build system, library and a Python interface.
GNU General Public License v3.0
22 stars 12 forks source link

Multi-threading #26

Open JoergRambau opened 4 years ago

JoergRambau commented 4 years ago

Dear qsopt_ex team,

I am Jörg Rambau from the university of Bayreuth. I am writing this as the author of TOPCOM. I have successfully built an interface to qsopt_ex for regularity checks of triangulations of point configurations, usable as an alternative to cddlib (Fukuda). However, using separate instances of the exact solver in multiple threads crashes the program in random places. It seems at first sight that the gmp memory management is global in qsopt_ex and not thread-safe.

My question is: is qsopt_ex expected to be thread-safe and I have made a mistake somewhere, or is it clear that several instances of the exact solver running in parallel threads will not work?

For my purpose, it would be the best if I could enforce the call of completely separate instances of the exact solver running lock-free, e.g., by thread-local storage for the global data. I have experimented with this myself, but it seems that "__thread", while making builtin types like "int" thread-local, fails to make mpq-structures from gmp thread-local. I also tried to compile qsopt_ex with c++ using "thread_local", but all the untyped preprocessor magic does not go through in c++.

I am developing mostly in Apple clang version 11.0.3 (clang-1103.0.32.59) and in various versions of gcc on ubuntu Linux, standard c++11.

Thanks a lot for clarifying! Jörg

jonls commented 4 years ago

Hi Jörg, I believe qsopt_ex is probably not thread-safe although I have not been involved in the original development of qsopt_ex and it's been a while since I looked at the code (as mentioned in the README I've simply forked the original qsopt_ex release to make some small improvements). The GMP docs mention that certain functions are not thread-safe and it appears some of these at least are used in the qsopt_ex code: https://gmplib.org/manual/Reentrancy. If you're interested in making some changes to improve multithreading compatibility, I'd be interested in merging those though I don't have a whole lot of time to get involved in improving stuff myself right now.

JoergRambau commented 4 years ago

Dear Jon,

Thanks anyway for the answer. I have tried several things, but it is difficult for me to untangle the preprocessor magic. Therefore, I did not find a solution. It seems that in C11 (Apple Clang) there is no way to effectively declare the global gmp structs as __thead_local, and it is virtually impossible to compile qsopt_ex with C++11 because of strict type checking.

For the time being, I leave it like this, and disable qsopt_ex for parallel execution in TOPCOM. It's a pity because it is really fast.

So long, Jörg

Am 14.06.2020 um 02:39 schrieb Jon Lund Steffensen notifications@github.com:

Hi Jörg, I believe qsopt_ex is probably not thread-safe although I have not been involved in the original development of qsopt_ex and it's been a while since I looked at the code (as mentioned in the README I've simply forked the original qsopt_ex release to make some small improvements). The GMP docs mention that certain functions are not thread-safe and it appears some of these at least are used in the qsopt_ex code: https://gmplib.org/manual/Reentrancy. If you're interested in making some changes to improve multithreading compatibility, I'd be interested in merging those though I don't have a whole lot of time to get involved in improving stuff myself right now.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Joerg Rambau .... LS Wirtschaftsmathematik, Raum 1.29 FAN-D ............/ // : Universitaet Bayreuth, 95440 Bayreuth, Germany //../ Phone: +49-921 55-7350 Sec: -7351 Fax: -847351 :._.// :..................... joerg.rambau@uni-bayreuth.de