R: [Help-glpk] xmalloc, thread-safety

[Giampaolo Tomassoni]

> -----Messaggio originale-----
> Da: address@hidden [mailto:help-glpk-
> 
> On Thu, 30 Aug 2007, Andrew Makhorin wrote:
> > To make glpk thread-safe you need to provide two platform-specific
> > routines lib_set_ptr and lib_get_ptr (see src/glplib03.c). By default
> > these routines store a pointer in the static memory, and currently
> > only a version for the windows dll is implemented.
> How hard is it to make a parallel version of GLPK at the moment? It
> seems
> like the new functionality in 4.20 and 4.21 may be directed towards
> that?
> Are there any plans to provide a parallel GLPK?

Hi Oscar,

for what I know, GLPK isn't that hard in parallelize. The only thinks to
take care of had already been spotted out by Andrew: xmalloc/xfree override
and lib_set/get_ptr.

Your xmalloc/xfree impl can simply be a wrapper for malloc/free, while the
pointer used by lib_set/get_ptr may even be left the way it is unless you
need different GLPK behavior in different threads with respect to message
and error printing. There are many malloc/free implementations around, which
are thread free and may sometimes improve performances with respect to the
one supplied, in example, by the GNU libc. Check them out.

Everything else may already be used with threading, as long as you don't run
the same GLPK problem in different threads.


> (Naturally, it is hard to make an efficient one, but let's say a
> parallel
> MILP solver which uses different branching rules in different threads.)

This means you have to create more LPX instances, load them with the same
data, and solve them in different threads with the wanted methods. Please
note that the "thread-safe" phrase generally means that provisions are
implemented such that calls to methods in an object are interlocked
(serialized) in such a way not to interfere each other. A completely
thread-safe implementation of the GLPK lib would not allow running
"different branching rules in different threads" on the same LPX instance...

I personally don't see any usefulness in improving multithreading support
above bringing the lib_set/get_ptr features to be instance-wide instead of
application-wide and implementing some kind of LPX clone() function. Method
interlocking would basically waste cpu cycles while not borrowing any real
improvement to the GLPK lib.

Instead, it *may* be useful to try to implement multithreading in solvers.
I'm not an expert of the GLPK's application domain, so I don't know how many
difficulties are hindered in this. But this is a completely different matter
than thread safeness...

Giampaolo

> 
> /Oscar
> 
> 
> _______________________________________________
> Help-glpk mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-glpk