[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