Re: GLPK and OPENMP - GLP_SIMPLEX running concurrently
On Wed, 13 May 2020, Sierra Ansuas, Juan Pablo wrote: The program is returning correct values as long as the call to glp_simplex is enclosed inside an OMP 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. Globals and statics used directly by GLPK. Globals and statics used by things GLP calls. -- Michael henne...@web.cs.ndsu.nodak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards
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 *Sent:* Thursday, March 26, 2020 6:46 PM *To:* bug-g...@gnu.org; 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 + > >> 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 200), Stack size limit per thread: 200MB (export >> OMP_STACKSIZE=20). 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
GLPK and OPENMP - GLP_SIMPLEX running concurrently
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 an OMP 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 Sent: Thursday, March 26, 2020 6:46 PM To: bug-g...@gnu.org; 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 + > >> 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 200), Stack size limit per thread: 200MB (export >> OMP_STACKSIZE=20). 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
