[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] GLPK re-endrant
From: |
Andrew Makhorin |
Subject: |
Re: [Help-glpk] GLPK re-endrant |
Date: |
Mon, 29 Jun 2009 22:06:27 +0300 |
> 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