Re: [Help-glpk] GLPK re-endrant

[Andrew Makhorin]

> Hello.. I am still in look for a re-endrant version of glpk..
> With the Google help I found:

> "Probably I have been misunderstood. Multitasking does not assume
> reenterability and vice versa, so even if glpk routines were reentrant
> (which they will in the next release), this would not involve
> parallelizing the branch-and-bound. Reenterability simply means that
> the code does not modify static data like reusability means that the
> code does not modify itself. In principle, any code can be easily made
> reentrant by using appropriate programming technique, i.e.
> reenterability is a property of the code, not of the algorithm.

> Andrew Makhorin"

> (http://osdir.com/ml/gnu.glpk/2003-10/msg00015.html)

> I am little confused, as Iast year I asked the same thing and I got
> answered that "non-reentrancy is only due to the LIBENV
> structure (see glplib.h), which is shared among more problems."

> I tried to have a look at the code even if I #39;m not a
> programmer.. on glplib02.c there is:

>  static void *tls = NULL;
> /* in a re-entrant version of the package this variable must be placed
>    in the Thread Local Storage (TLS) */

> Of course I don #39;t understand anything of it, but with the help
> of Wikipedia I read that, at least in GNU/C++ you have to use the
> keyword "__thread" ... so.. don #39;t tell me that it is enought to
> have it like:  "static __thread void *tls = NULL; " to have glpk
> re-endrant ?? Or it is already re-endrant (it would be fantastic ;-) )
> ??

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.


Andrew Makhorin