[Help-glpk] Re: GPLK 4.2 Win32 Thread safe library is broken

[Andrew Makhorin]

>The win32 thread safe library cannot be used
>with java or other enviroments (all?)
>with garbage colletion.
>
>The threading style uses allocation of the
>"hidden pointer" from Thread local storage.
>
>This requires that the objects are not passed
>from one thread to another.

Glpk routines have no synchronization to access/modify components of
program objects passed by means of pointers, so if an LPX problem
object is created by one thread, it must not be accessed/modified by
another thread. This is a natural requirement.

Nevertheless, if there is a need to have multithreaded processing of
the same LPX problem object or, more generally, of the same workspace
which may include several LPX objects (for example, in interactive
applications), this can be implemented via client/server technique,
when one thread holds all problem objects and handles requests from
other threads. This, however, should be implemented outside of glpk.

>Garbage collector is running on a separate thread,
>and therefore will mess things up, even if you were
>running only one thread.

The garbage collector may reorganize only the memory allocated in Java
environment. It cannot (and I am sure it does not) alter glpk objects
at least because it knows nothing about them. Data structures are
declared in glpk headers only for convenience. Formally only abstract
pointers to program objects are available outside of glpk.

>3) Use Mutex to protect things pointed by hidden_pointer
>from concurrent access. (My patches version 4 uses this.)

Glpk is written in ISO C which has no features like threads, mutexes,
etc. It is not a system program. It is a package intended for numeric
computations independently on platforms on which it is running. So using
platform-specific and therefore non-standard features just to reach
particular effects is, in my opinion, extremely bad idea, because this
would make glpk non-portable. Unfortunately, there is a plenty of
excellent packages (not only for numeric computations), which could
work on *any* platform, but they do not merely because their developers
used some non-standard language constructions, library functions, etc.
And due to that other people need to spend a lot of efforts and time
just to port such packages from one platform to another. (I am talking
only about free software.) I think that all platform-specific features
should be implemented separately and outside of glpk (at least to
simplify its maintenance :+).

Andrew Makhorin