Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

Paul,

> I'm thinking since it is written in C, and C is source compatible
> with C++, since C++ does support locking in threads, if one was to
> treat it as a C++ app written mostly in C, it may be possible to
> multi-thread it without a huge rewrite?

> I say this without any knowledge of the GLPK source at all or how
> it works internally, so please bear my comments in that light, but in
> terms of locking, if the data structures being used for each
> computation are completely separate copies in each thread, I'm not
> sure where the demand for locking arises, perhaps you could elaborate
> a little?

> To get thread safety now, I can synchronize access to the JNI lib
> in Java to enforce single-threadness, but of course it means if I have
> multiple computations wanting to use GLPK, which I do, they have to
> queue for it and I have a central bottleneck.

> So I guess I just don't mean thread safe, I mean thread hot, as in
> I can have multiple GLPK computations going in separate threads
> simultaneously which don't need to synchronize on anything or if they
> do, it's for a very small part of the computation rather than the
> entire duration.

You may make glpk code reenterable by replacing the routines
tls_set_ptr and tls_get_ptr in file glpenv02.c (v4.43) with a
appropriate reentrant version. The variable tls (declared as static
in the original non-reentrant version) is a pointer to the glpk
environment. In the reentrant version it must be allocated in the
thread local storage, i.e. each thread should have its own instance
of that variable. This feature is not implemented in glpk due to
portability issues. Please note that reenterability does not mean
thread-safety, i.e. you can call glpk api routines from different
threads, however, each problem object (glp_prob) can be used only in
that thread where it was created.


Andrew Makhorin