help-glpk
[Top][All Lists]
Advanced

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

Re: [Help-glpk] Re: Reentrant glpk with JNI


From: Daniel Aaron Issen
Subject: Re: [Help-glpk] Re: Reentrant glpk with JNI
Date: Tue, 11 Nov 2003 16:51:41 -0800

>>>>> "Andrew" == Andrew Makhorin <address@hidden> writes:

    >> I need a reentrant version of glpk. I need to call it from Java on
    >> linux and possibly win32 platforms.  I did see the thread at
    >> http://mail.gnu.org/archive/html/help-glpk/2003-10/msg00001.html It
    >> looks like reentrancy was not included in glpk 4.1. Is the best way to
    >> make it reentrant currently to use Joonas' patch 4 at
    >> http://www.hut.fi/~jkekoni/glpk-t/ ?  I dont need the file routines to
    >> be reentrant.  Are there any gotchas with using this patched version
    >> with Java?

    Andrew> Joonas implemented reentrancy via mutex objects that, however, is
    Andrew> *not* in the spirit of the glpk design. Since glpk does not
    Andrew> provide parallel algorithms, there is no sense to share program
    Andrew> objects between different threads.

    Andrew> You can build a reenterant W32 dll for glpk replacing the files
    Andrew> glplib1.c and glpmps.c by their reentrant versions (see
    Andrew> glplib1a.c and glpmps.c in the attachment). Note that: a) the
    Andrew> interior point routine lpx_interior must not be used in reentrant
    Andrew> applications; b) no thread must access the problem object created
    Andrew> by another thread.

    Andrew> To build the dll you simply need to include all files from the
    Andrew> source subdirectory into the project in a usual way (within
    Andrew> ide). No special settings are
    Andrew> required._______________________________________________
    Andrew> Help-glpk mailing list address@hidden
    Andrew> http://mail.gnu.org/mailman/listinfo/help-glpk

Although there aren't any parallel algorithms, the ability to have multiple
threads work on different models at the same time has a huge benefit.  I've
used this approach when doing column generation where the subproblems were
sent to child threads.  The mutex approach doesn't work for this very well
because the total throughput of the system is gated.  better would be to just
create a model data structure and put all globals on that and pass pointers
to said data structure to each routine that is stateless.  each thread would
create it's own model and you'd have a thread safe, re-entrant system without
locking.  

just my 2 cents.

Daniel

-- 
Daniel Issen
address@hidden




reply via email to

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