[Top][All Lists]
[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