[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Help-glpk] Compilation problems on RH Enterprice...

From: Giampaolo Tomassoni
Subject: RE: [Help-glpk] Compilation problems on RH Enterprice...
Date: Thu, 5 Jun 2008 20:07:56 +0200

> -----Original Message-----
> From: address@hidden [mailto:help-
> address@hidden On Behalf Of Antonello
> Lobianco
> ...omissis...
> 'Going little bit OT.. are there any plan to make glpk at least
> reendrant?? I
> need to solve several independent small problems, and I don't know if I
> can
> spread them in several threads...

I didn't participate to coding the GLPK library, so I may easily be wrong.
However, it seems to me that its non-reentrancy is only due to the LIBENV
structure (see glplib.h), which is shared among more problems. 

This holding, one way to make the GLPK library more re-entrant is to define
your own version of the lib_set_ptr() and lib_get_ptr() functions, such that
they store and return a pointer to a thread-local LIBENV structure.

This holds as long as you build, solve and destroy a problem in the same
thread. I mean, you can start many threads, but each one have to build,
solve and destroy its own problems. It would be dangerous to build a problem
in a thread and solve or destroy it in another since, in example, the GLPK's
memory allocation code uses the mem_ptr member of the LIBENV struct to
manage memory allocation.

You could, however, overcame also this limit by providing your own,
thread-safe versions of the umalloc, ucalloc and ufree functions. In most
thread-supporting environments, you simply have to use the malloc, calloc
and free functions supplied by the environment itself: they are already
thread-safe and this way the GLPK library would not rely anymore on the
LIBENV struct for memory allocation. 



> Thanks,
>   Antonello
> _______________________________________________
> Help-glpk mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]