Re: [Help-glpk] Multithreading/parallelization

[Harley Mackenzie]

My problem with understanding your requirement was that I only use the
command line glpsol and don't link my problem to the C API code. You
have raised a very important requirement for the project that we need
BOTH re-entrancy and multi-threaded operation.

The two requirements are related but distinct requirements.
Multi-threaded operation requires protection of the single global
problem data structure to be controlled and managed, whereas re-entrancy
for multiple LP problems will require separate global data structures
for each problem, possibly using thread local storage (TLS), and may
also use multiple threads within each separate problem. The global
exception routines that you mentioned will also require handling for
both cases.

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