Andrew. 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. Thx. Paul -----Original Message----- From: Andrew Makhorin [mailto:m...@gnu.org] Sent: 13 April 2010 20:05 To: Hammond, Paul (IDEAS) Cc: help-glpk@gnu.org Subject: Re: [Help-glpk] Thread safety of GLPK > I #8217;d like to know if GLPK (the C lib) is not thread > safe? No, glpk is not thread safe. > If not, are there any plans to ever make it thread safe? We get > occasional core dumps in a multi-threaded environment which we think are > related to thread safety as we get a SIGSEGV inside GLPK. Thread safety (unlike re-enterability) requires locking/unlocking program objects used by concurrent threads. Since the standard C does not provide such a feature, there are no plans in this direction. I'm just wondering how you would use glpk if it were thread safe? Thanks. Andrew Makhorin -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. _______________________________________________ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
