Re: GLPK and OPENMP - GLP_SIMPLEX running concurrently

Hello Sierra !


My 2 cents, have you tried to compile with -fsanitize=thread to see if 
it catch the problem ?

https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual


Cheers !


On 13/5/20 14:50, Sierra Ansuas, Juan Pablo wrote:
> Hello, and sorry for insisting about this issue.
>
> The program is returning correct values as long as the call to 
> glp_simplex is enclosed inside anOMP CRITICAL region. This is the only 
> part requiring a mutex. The rest of the glp_* functions are called 
> concurrently by several threads with no issue at all.
>
> When the OMP CRITICAL surrounding glp_simplex is removed, the calls to 
> *glp_get_row_dual* and *glp_get_col_prim* return different values.
>
> Each thread uses a different glp_prob, which is built from scratch by 
> the same thread and used by the same thread.
>
> Each thread also changes some values on the RHS and calls glp_simplex 
> several times. After that, each thread deletes its own GLPK problem.
>
> What could be affecting the way glp_simplex works? Is there anything 
> you would suggest looking at?
>
> I'm very grateful for the help I've received  so far.
>
> Regards,
> Juan Pablo.
>
> ------------------------------------------------------------------------
>
> *Subject:* Re: [Fwd: Possible bug in GLPK - Error detected in file 
> env/alloc.c at line 72]
>
> Dear Heinrich,
>
>
> I have been working on the project that I have been assigned and 
> applied the changes you suggested with successful results.
>
>
> - glp_prob objects are created, used and deleted by the same thread
> - GLPK lib compiled with reentrancy support (checking whether to 
> enable reentrancy support... yes)
>
> The program is no longer crashing. /Thank you./
>
> I have looked at the multiseed.c example. The main difference between 
> that example and the project that I am working on is that I build a 
> glp_prob from scratch, then using glp_copy_prob make as many copies as 
> processors are available on the machine. Each thread changes a couple 
> values on the right hand side and runs the simplex again, without 
> building the glp_prob again or starting the search from scratch.
>
> However, the problem that I am now facing is that when several threads 
> are calling glp_simplex at the same time, some values appear to be 
> mixed up such as those returned by glp_get_row_dual. Adding a mutex 
> (OMP CRITICAL) that contains_only the glp_simplex call_ makes the 
> problem go away and no issues can be seen, the program generates the 
> expected output data and ends without errors.
>
> I have looked at the error and output handling contained in the 
> multiseed.c example. I ended up using glp_open_tee and redirecting the 
> output of each thread to a separate file. No warnings were displayed.
>
> Thank you very much for your help.
>
> Regards,
> Juan Pablo
>
> ------------------------------------------------------------------------
> *From:* Heinrich Schuchardt <[email protected]>
> *Sent:* Thursday, March 26, 2020 6:46 PM
> *To:* [email protected]; Sierra Ansuas, Juan Pablo
> *Cc:* Andrew Makhorin
> *Subject:* Re: [Fwd: Possible bug in GLPK - Error detected in file 
> env/alloc.c at line 72]
> On 3/25/20 8:23 PM, Andrew Makhorin wrote:
> > -------- Forwarded Message --------
> > Date: Wed, 25 Mar 2020 18:34:56 +0000
> >
> >> Dear GLPK mantainer(s),
> >>
> >> I am having problems when trying to run the GLPK solver in a multi-
> >> threaded fashion using its C API and OpenMP. While the solver does
> >> appear to work, an error comes up when trying to free the memory with
> >> glp_delete_prob:
> >>
> >> glp_free: memory allocation error
> >> Error detected in file env/alloc.c at line 72
> >>
> >> I am no GLPK expert but I would be very grateful if you could check
> >> the provided source code and determine whether this is being caused
> >> by a bug or a simple beginner mistake.
> >>
> >> Running on an eight core processor, 8GiB ram. Stack size limit: 2GB
> >> (ulimit -s 2000000), Stack size limit per thread: 200MB (export
> >> OMP_STACKSIZE=200000). Provided source makes little sense but is
> >> quite short and reproduces the problem every time. Compile command is
> >> as follows:
> >>
> >> gcc test_c.c  -o test_c -fopenmp -I/home/user/libglpk/glpk-
> >> 4.65/include /home/user/libglpk/glpk-4.65/src/.libs/libglpk.so.40.3.0
> >>
> >>
> >> Regards,
> >>
> >> Juan Pablo Sierra
>
> Hello Juan,
>
> Did you compile GLPK with '--enable-reentrant=yes'?
>
> You are creating all problems in one thread and then call the solver in
> separate threads. This is not supported by GLPK.
>
> Please, have a look at:
> glpk-4.65/examples/threads/multiseed.c
>
> Here all GLPK library calls needed for each individual model are called
> within the same separate thread.
>
> Please, have a look at the error and output handling in the example too.
>
> Best regards
>
> Heinrich
> La información contenida en este mensaje y en cualquier archivo 
> adjunto, es confidencial y está dirigido únicamente al destinatario 
> del mensaje. Si Ud. no es el destinatario correcto por favor notifique 
> al remitente respondiendo este mensaje y elimine inmediatamente de su 
> sistema el e-mail y los posibles archivos adjuntos. Está prohibida 
> cualquier utilización, difusión o copia de este e-mail por cualquier 
> persona o entidad que no sean las especificas destinatarias del 
> mensaje. UTE no acepta ninguna responsabilidad con respecto a 
> cualquier comunicación que haya sido emitida incumpliendo nuestra 
> Política de Seguridad de la Información, así como lo previsto en la 
> Ley 18.331 de Protección de Datos Personales y Ley 18381 de Acceso a 
> la Información Pública