Re: [Help-glpk] Parallel runs of glpk

[Mathieu Dutour]

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

Mathieu,

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

{

}

to

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

you.

 

Best regards,

Best regard to you too,

  Mathieu Dutour Sikiric