[Top][All Lists]

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

Re: [Help-glpk] Parallel runs of glpk

From: Mathieu Dutour
Subject: Re: [Help-glpk] Parallel runs of glpk
Date: Sun, 18 Dec 2016 14:26:56 +0100

On 18 December 2016 at 13:09, Andrew Makhorin <address@hidden> wrote:

> I think I can solve the problem by extending the second solution
> and having it backward compatible. It suffices to have
> reentrant functions that take env as argument and non-reentrant
> functions that takes no env argument.
> So, we are still backward compatible but offer a reentrant
> alternative.
> Are you interested? I think it would be nice to finally address the
> issue.

Glpk is a serial code; it has no features to run in parallel. So, as I
explained in my previous post, there is no sense to make it thread-safe.
If it is necessary to solve several *independent* problems at the same
time (for example, on a multi-core CPU), it is sufficient to run several
instances of glpk as separate processes, in which case thread-safety is
not needed. Replacing glp_set/get_tls with a reenterant version gives
the same effect, but allows to run multiple instances of glpk within the
same process that sometimes may be preferred. I think this is normal for
non-interactive applications that perform numerical computations.
Hi Andrew,

thank you for your message. The confusion was on my side. I wrote
"thread safe" when I meant reentrant. That is several process solving
independent problems. GLPK remains a serial code, but essentially can
be used like a function, just like "cos".

The tls_set_ptr / tls_get_ptr are the source of the problem because their
use forbid for rather artificial reason the use of GLPK in concurrent program.

The document that you send address the issue but actually do not completely
and as you mentioned in a non-portable way. The "thread_local" or the
other replacement do not really address the problem since the pointer for
env remains a global variable.

What I propose is a definitive solution of the problem. Features:
1) The code remains backward compatible. But the old functions retains
the same problem as before.
2) There would be some new function "_reentrant" that can be use
in concurrent program. Those function should NOT USE the tls_get_ptr
nor any similar functions. That is it does not have side effects.
3) no large code increase. For a functions of the API FCT, the code
changes from
void FCT(.....)

void FCT_reentrant(....., ENV* env)
void FCT(....)
   ENV* env=tls_get_ptr();
   FCT_reentrant(....., env);

I think this is the cleanest solution to the problem. If you
agree with me, I can program the patch and submit it to
Best regards,
Best regard to you too,

  Mathieu Dutour Sikiric

reply via email to

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