[Help-glpk] Clarification about threading issues

[Joonas Timo Taavetti Kekoni]

> >reentrant currently to use Joonas' patch 4 at
 ....
> >Are there any gotchas with using this patched version with Java?

No it is designed to work with java. There is also java based test
probgram. There are also win32 and linux dll's in the same adress.

Needles to say that the patches have not yet tested that much.

> Joonas implemented reentrancy via mutex objects that, however, is *not*
> in the spirit of the glpk design.

> Since glpk does not provide parallel
> algorithms, there is no sense to share program objects between different
> threads.
                GARBAGE COLLECTION NEEDS THIS! (at least some...)
                ------------------------------

        The ufree ufopen etc rutines use
        instansify singleton object on
        process context with 1st called.

        The mutex is only reasonable way to allocate and use
        such object thread safely.

        I tried to use thread_local storage. It worked until
        java's garbage collector started collecting them and
        fails at that instance. (Patch 3)

        The reason is that garbage collector is run in different
        thread and cannot therefore access the same thread local.
        PERIOD.

        I think this ufopen/umalloc thing should be
        tied to each LPX object context.
        Unfortunately this happens to affect the entire
        structure of the program, since not all functions
        can access the LPX object.

        So this would require a lot of rewriting.

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

I have worked this as a part of my patch. Everything
allocated globally is inserted into a struct that is passed
between the functions. Not clean but works.

This is probably not tested by java based test program?

>b) no thread must access the problem object created by another thread.

Nope. The newest version of my patch uses mutex to globally
allocaled umalloc/ufopen thing and allows different threads to
access the same objects(but naturally not concurrently.(

Nothing is allocated in thread local context anymore,
that was patch version 3 and I got rid of that
for forementioned reasons.


BTW: there is precompiled java binaries W32/Linux in the directory
that do not have concurrent MPS loding.