help-glpk
[Top][All Lists]
Advanced

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

Re: [Help-glpk] Reenterable patch for GLPK-4.47


From: Dmitry Nadezhin
Subject: Re: [Help-glpk] Reenterable patch for GLPK-4.47
Date: Mon, 21 Jan 2013 19:43:38 +0300

> Thank you. However, do you mean reenterability or thread-safety? These
> issues are often mixed up. And another question: in your opinion, how
> one could use a reenterable (or thread-safe) version of glpk?

I mean reenterability.

I can tell why I desire reenterant GLPK in my application.
My application searches for optimal parameters for thermocompensated
Crystal oscillators.
After mesurement of 64 oscillators, I need to launch a separate
medium-size optimization task for each of them.
Initially I launched them as separate OS processes, it was not convinient.
My application is written in Java. I bind GLPK to java with glue
interface based on JNA.
http://en.wikipedia.org/wiki/Java_Native_Access
Java has nice concurrent framework I want to use it.
I want to launch optimization tasks (glp_probs) in different Java Threads.
No synchronization is necessary, because tasks don't interact with each other.

Solution with thread-local GLPK environment helped me to run GLPK
tasks in different Java Threads.
Thank you for providing glpenv02.c !
However, there was an issue. Java usually don't require to free unused
objects. They are  gathered by garbage-collector.
Java runtime executes object's method "finalize" before erasing unused
object, Method "finalize" of my Java wrapper of glp_prob
was implemented as "glp_delete_prob".
Garbage collector may run in a separate thread. Thread-local GLPK
signalled error when a glp_problem was allocated in one thread,
and then it was freed in another thread by garbage collector. I had to
insert explicit "glp_delete_prob" in the end of each task.
I know that this is usual style in C, but this is aside of Java style.

I think that it would be nice if ENV structure was not thread-local
but instead it was a part of "glp_prob".
However, this change breaks existing API. So now I'm not sure what is
the best patch.

> As to patches, I see three ways:
>
> i) post them to the help-glpk mailing list as a gzipped attachment,
> providing necessary information in the message body and a subject line
> suitable for the search;
>
> ii) add a topic to http://en.wikibooks.org/wiki/GLPK and include the
> patches there;
>
> iii) officially glpk is hosted on GNU Savannah;
> see http://savannah.gnu.org/projects/glpk (though currently I don't use
> this service). I could add you to the project member list, so you could
> upload patches to the project repository.

As a first step, I put a new section into the Wikibook. It collects
information scattered in the mail list.
http://en.wikibooks.org/wiki/GLPK/Using_the_GLPK_callable_library#Reenterability



reply via email to

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