Re: [Help-glpk] GLPK re-endrant

[xypron]

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.