Re: [Help-glpk] Multithreading/parallelization

[glpk xypron]

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