> -----Messaggio originale----- > Da: [EMAIL PROTECTED] [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 > [email protected] > http://lists.gnu.org/mailman/listinfo/help-glpk _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
