[Help-glpk] Re: Clarification about threading issues

[Andrew Makhorin]

> > Since glpk does not provide parallel
> > algorithms, there is no sense to share program objects between different
> > threads.
>               GARBAGE COLLECTION NEEDS THIS! (at least some...)
>               ------------------------------
>
>       The ufree ufopen etc rutines use
>       instansify singleton object on
>       process context with 1st called.
>
>       The mutex is only reasonable way to allocate and use
>       such object thread safely.

I meant program objects created by glpk routines. If each thread is
assigned its own LIBENV (a low-level data structure used by ufree,
ufopen etc.), there cannot be conflicts between threads. Please look at
glplib1a.c which I attached to my previous mail.

>       I tried to use thread_local storage. It worked until
>       java's garbage collector started collecting them and
>       fails at that instance. (Patch 3)

Are you sure that the java garbage collector does something with tls
created by a non-java application?

Andrew Makhorin