Re: [Help-glpk] Multithreading/parallelization

[Harley Mackenzie]

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

  address@hidden
  www.hardsoftware.com
  + 61 3 5222 3435