Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> ...but if you implement locking, then then you will have thread-safety
> but not full concurrency (at least in the critical sections). You'd be
> better off collecting all the non-sharable state in a structure that
> that each thread creates and passes around as an extra function
> parameter - i.e. make the code re-entrant (no locks) such that you
> have true concurrency.

Exactly this technique is used in glpk: all common variables are
stored in the glpk environment block which is dynamically allocated
by glp_init_env and deallocated by glp_free_env. However, a pointer
to this block is stored in a static variable.

> Andrew, that's pretty interesting - I thought it would have taken a
> lot more work to make the code re-entrant, but seems like it's pretty
> much there.
> 
> I wonder if it would be feasible to re-implement this using the posix
> threads API and then use this API adapter on Windows, such that the
> re-entrant code would be portable across all platforms?

It is possible. A while ago I implemented a reenterable version
using posix threads (I will try to find the code); I don't remember,
but there were some portability issues, so I decided not to include
that version in the official glpk distribution.