[Top][All Lists]

[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.
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 and include the
> patches there;
> iii) officially glpk is hosted on GNU Savannah;
> see (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.

reply via email to

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