Andrew Makhorin a écrit :
What I need is indeed reentrability : what I want to do is solve
different subproblems of the same problem in parallel, so each LPX is
local to one thread only.
This must work.
In fact, I forgot to mention one crucial thing : even though each LPX is
handled by only one thread, it happens that one LPX is solved, then
destroyed by a thread which is different from the thread which generated
the LPX. Hence a bunch of funny error messages from ufree.
I think it should be possible to implement an GNU/Linux equivalent
for your TLS-based routines, using the pthread_setspecific family of
routines of the POSIX threads library. I can have a look at it, if
you like.
If you are using posix pthreads, writing that two routines must be
easy to you; see w32 version and examples/mtsamp.c as an example.
I did not include the posix version in the distribution because of its
incompatibility with GNU/Linux.
I did implement a posix threads version of your TLS-based version, but
it didn't solve the ufree errors.
Actually, I solved my problem by recompiling GLPK with the GLP_HUGE_MEM
constant defined, so that umalloc/ufree are just compiled as wrappers
for malloc/free, which are reentrant and allow exchange of malloced
blocks between threads.
regards,
François
_______________________________________________
Help-glpk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-glpk
