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

[Joonas Timo Taavetti Kekoni]

> 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.
Again, which is incompatible with garbage collection,
unless you put that "hidden_pointer" inside that LPX object.

> Nevertheless, if there is a need to have multithreaded processing of
> the same LPX problem object
Having mulple thread calling the object, BUT NOT at the same time
is a requirement for linking the object inside a garbage collected
enviroment.

This is different thing than having multiple threads calling the same
methods of a single object at the same time.(Which does not make sense...)

> 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.

We are not talking about reorganisation, just deallocation.

It does alter GLPK objects, because deallocation is
altering,and does not know howto and that is creating the problems.

When a java program creates new GLK object it will be bound to the java
object by JNI.

It will be released when JWM garbage collector calls
finalize() method before deallocating the objects.

( All java objects will be called finalized method by garbage
collector if they have one. Most do not. )

JWM garbage collector will call finalize() .
finalize() will call the GLPK deallcation by JNI,
so it __does__ happen  on different thread.

** YES, JWM garbage collector IS deallocating the memory of GLPK indirectly! **

Yet,this is _the_ problem.

It can be bypassed by finalize() not calling GLPK deallocation
and adding  close() method that must be called by the
wery thread that created the Object and have this close
method calling deallocation of glpk.

Naturally this means a memory leak when if close()
is not called before garbage collection.

(This is slighly un javaish, but is done even
in standard packages at least in JDBC.)

> Glpk is written in ISO C which has no features like threads, mutexes,
> etc.

It does not prevent you from doing a macro functions for
syncronisation that are defined to empty be default.
#define get_mutex(x)
#define release_mutex(x)

Then you can add a platform dependent part like you have done
at this time.

>It is not a system program.
It is a linkable library and therefore meant to be used as part
of other programs(?).

Yet threading is requirment, not a nice to have feature these days.

> I think that all platform-specific features
> should be implemented separately and outside of glpk (at least to
> simplify its maintenance :+).

I think that what i am proposing does this in reasonable
amount and is highly trivial compared to other things inside GLPK.

--
You probably agree with me that the best place of hidden_pointer
would be is inside GPLK object, since it would be thread safe without
platform dependent functionality.

( But this is untrivial change to do, otherwise it would be there
allready.)