> ...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. _______________________________________________ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
