In the case of multiple LPs couldn't you just use the existing single threaded version and run separate instances of the application as I know members of this list already do? What is being gained by running this case with one instance of the application.
I am just trying to understand the different scenarios that need to be considered and I suspect that it will take a bit of time to understand all of the different use cases for multi threaded execution. Harley On Sun, Dec 16, 2012, at 0:32, glpk xypron wrote: > Hello Harley, > > think of a multi threaded application that has multiple LPs to be solved > at > once. Let one of the threads hit xerror or xassert. If you stick to only > one > environment you will not be able to use the error hook function to > gracefully > terminate this one thread. You will be forced to abort the whole > application. > > It is a different story if you only want to use multiple threads within > the MIP solver. In that case you might be able to stick to one > environment. > > Best regards > > Heinrich Schuchardt > > -------- Original-Nachricht -------- > > Datum: Sat, 15 Dec 2012 20:05:43 +1100 > > Betreff: Re: [Help-glpk] Multithreading/parallelization > > > Thanks for the comments. > > > > Your point is very true about the environment structures as my item 2 > > was meant to cover all of the data structures. However, I hadn't > > realised that this step was a lot larger than I had anticipated and > > there many dependent routines that also needed to be changed. I have > > only been basing my initial assessment on what needed to be done on the > > many discussions over the past few years. I havent engaged in any > > detailed assessment of the code yet. > > > > Is it necessary to have multiple structures or could a single > > environment structure be used with controlled access to the single > > structure through the use of mutexes when accessed from multiple > > threads? I may be missing something fundamental here. > > > > Also, I certainly definitely agree that for the code to move forward, we > > do need to do this work. > > > > I shall gather any further comments and put together a more detailed > > work plan. > > > > Harley > > > > On Sat, Dec 15, 2012, at 17:31, glpk xypron wrote: > > > Hello Harley, > > > > > > GLPK not being threadsafe is hindering integration into other tools as > > > well as reducing solution speed for MIP problems. > > > > > > The issue has been recurring for many years, and obviously is an issue > > > for enough users to deserve being fixed. > > > > > > In your mail you indicated some necessary work steps. I see the > > following > > > additional work: > > > > > > Currently GLPK has one environment structure which holds all memory > > > references and which is destroyed in case of an error. To make GLPK > > > thread safe it is necessary to have separate environment structures for > > > each instance of a the GLPK problem object (glp_prob). This has > > > implications on several API functions, e.g. glp_free_env, > > glp_error_hook, > > > glp_malloc. Furthermore all functions calling xerror or xassert will be > > > affected. > > > > > > The effort needed is considerable and hence I appreciate your idea to > > > develop a solution in a community working environment. Before starting I > > > would be interested to hear about Andrew's vision for GLPK. > > > > > > Best regards > > > > > > Heinrich Schuchardt ----- Dr. Harley Mackenzie HARD software [email protected] www.hardsoftware.com + 61 3 5222 3435 _______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
