Andrew Makhorin wrote: > > No, currently glpk is not reentrant. It uses standard C functions > strerror and strtok, which are non-reentrant. In principle, it would > be possible to replace them with strerror_r and strtok_r as well as > add the attribute '__thread' to the 'tls' pointer when such features > are supported by a particular platform (I mean configure script). > However, I see no gain, because even if glpk were reentrant, the > application program could not use the same instance of glpk program > objects (like glp_prob) from different threads. On the other hand, > if it calls glpk routines only from one thread, reenterability is not > needed. > Hello Andrew,
I see two fields of applications for threading in GLPK. ILOG describes that many MIPs can be solved >= 1.7 times faster using multiple threads and shared memory. http://www.ilog.com/optimization/the-right-hand-side/1/TA_Parallel_CPLEX_Dong.html http://www.ilog.com/optimization/the-right-hand-side/1/TA_Parallel_CPLEX_Dong.html In case of column generation (like in the CLSP) multiple subproblems could be solved at the same time on separate cores. My understanding is that a major group of functions that has a problem with threading is the memory allocation (xfree, ...). See http://lists.gnu.org/archive/html/help-glpk/2007-08/msg00040.html http://lists.gnu.org/archive/html/help-glpk/2007-08/msg00040.html Best regards Xypron -- View this message in context: http://www.nabble.com/GLPK-re-endrant-tp24256046p24266555.html Sent from the Gnu - GLPK - Help mailing list archive at Nabble.com. _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
