Re: [Help-glpk] Thread Safety of GLPK
On 08/30/2017 08:13 PM, Simone Atzeni wrote: > Heinrich, > > looking at the thread example I added the glp_config("TLS”) check and I was > getting a undefined reference which made me realized that for some reason I > was linking to a wrong and old GLPK library instead of the one manually > compiled by me. > > So it’s all good now. Nice to hear. Still I heavily recommend to use an error hook function. Otherwise an error in GLPK will stop your whole application. Best regards. Heinrich > > Thanks for your help! > Best, > Simone > >> On Aug 30, 2017, at 12:04, Heinrich Schuchardt wrote: >> >> On 08/30/2017 07:23 PM, Simone Atzeni wrote: >>> Hi Heinrich, >>> >>> you mean the line: >>> >>> std::string filename = "ilp_problem" + std::to_string(rand()) + ".lp”; >>> >>> or the problem name: >>> >>> glp_set_prob_name(mip, "overlap”); >>> >>> The filename is not used at all in the function, it was just something I >>> forgot to remove. >> >> Sorry I got that wrong. >> >> Giving the problem the same name should not be a problem because the >> name is in thread local memory. >> >> Please, add the error catching code as in the example code. >> >> If this catches your error you should be able identify the responsible >> line of code by setting a variable after each line and writing it to the >> console in the error hook function. >> >> Regards >> >> Heinrich >> >> >>> >>> Thanks, >>> Simone >>> >>> On Aug 30, 2017, at 11:05, Heinrich Schuchardt wrote: Hello Simone, in your program all threads create random file names that are generated from the same name space. The initial value of the random number generator probably will be the same for all threads. This will lead to two threads trying to write the same file. Either use a Singleton for the file name creation or use separate namespaces by refering to the thread id like: solution--counter.txt Your code lacks proper error handling for errors. You should path unique filenames to the threads. Please, have a look at glpk-4.63/examples/threads. It shows how to handle GLPK errors in multithreaded applications. The example code creates one thread per problem. In a real world program you should use a thread pool. Best regards Heinrich Schuchardt On 08/30/2017 05:51 AM, Simone Atzeni wrote: > Hi all, > > thanks for your answers. > I updated to version 4.63, but I keep getting errors such as > "segmentation fault" or "glp_free: memory allocation error”. > > I have a function, with a few parameters in input, which creates the MIP > and solve it (attached the function which creates the MIP). > This function is called by multiple threads with different parameters and > they do not share any data. > As soon as I call the function within a mutex lock/unlock everything > works fine. > > I compiled the GLPK package with Clang/LLVM 4.9 which has support for > TLS, so I think everything should be fine. > Do I need to do something else to make GLPK thread safe? > > Thanks. > Best, > Simone >>> >>> > > ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
Heinrich, looking at the thread example I added the glp_config("TLS”) check and I was getting a undefined reference which made me realized that for some reason I was linking to a wrong and old GLPK library instead of the one manually compiled by me. So it’s all good now. Thanks for your help! Best, Simone > On Aug 30, 2017, at 12:04, Heinrich Schuchardt wrote: > > On 08/30/2017 07:23 PM, Simone Atzeni wrote: >> Hi Heinrich, >> >> you mean the line: >> >> std::string filename = "ilp_problem" + std::to_string(rand()) + ".lp”; >> >> or the problem name: >> >> glp_set_prob_name(mip, "overlap”); >> >> The filename is not used at all in the function, it was just something I >> forgot to remove. > > Sorry I got that wrong. > > Giving the problem the same name should not be a problem because the > name is in thread local memory. > > Please, add the error catching code as in the example code. > > If this catches your error you should be able identify the responsible > line of code by setting a variable after each line and writing it to the > console in the error hook function. > > Regards > > Heinrich > > >> >> Thanks, >> Simone >> >> >>> On Aug 30, 2017, at 11:05, Heinrich Schuchardt wrote: >>> >>> Hello Simone, >>> >>> in your program all threads create random file names that are generated >>> from the same name space. The initial value of the random number >>> generator probably will be the same for all threads. This will lead to >>> two threads trying to write the same file. >>> >>> Either use a Singleton for the file name creation or use separate >>> namespaces by refering to the thread id like: >>> solution--counter.txt >>> >>> Your code lacks proper error handling for errors. >>> >>> You should path unique filenames to the threads. >>> >>> Please, have a look at glpk-4.63/examples/threads. It shows how to >>> handle GLPK errors in multithreaded applications. >>> >>> The example code creates one thread per problem. In a real world program >>> you should use a thread pool. >>> >>> Best regards >>> >>> Heinrich Schuchardt >>> >>> >>> On 08/30/2017 05:51 AM, Simone Atzeni wrote: Hi all, thanks for your answers. I updated to version 4.63, but I keep getting errors such as "segmentation fault" or "glp_free: memory allocation error”. I have a function, with a few parameters in input, which creates the MIP and solve it (attached the function which creates the MIP). This function is called by multiple threads with different parameters and they do not share any data. As soon as I call the function within a mutex lock/unlock everything works fine. I compiled the GLPK package with Clang/LLVM 4.9 which has support for TLS, so I think everything should be fine. Do I need to do something else to make GLPK thread safe? Thanks. Best, Simone >> >> ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
On 08/30/2017 07:23 PM, Simone Atzeni wrote: > Hi Heinrich, > > you mean the line: > > std::string filename = "ilp_problem" + std::to_string(rand()) + ".lp”; > > or the problem name: > > glp_set_prob_name(mip, "overlap”); > > The filename is not used at all in the function, it was just something I > forgot to remove. Sorry I got that wrong. Giving the problem the same name should not be a problem because the name is in thread local memory. Please, add the error catching code as in the example code. If this catches your error you should be able identify the responsible line of code by setting a variable after each line and writing it to the console in the error hook function. Regards Heinrich > > Thanks, > Simone > > >> On Aug 30, 2017, at 11:05, Heinrich Schuchardt wrote: >> >> Hello Simone, >> >> in your program all threads create random file names that are generated >> from the same name space. The initial value of the random number >> generator probably will be the same for all threads. This will lead to >> two threads trying to write the same file. >> >> Either use a Singleton for the file name creation or use separate >> namespaces by refering to the thread id like: >> solution--counter.txt >> >> Your code lacks proper error handling for errors. >> >> You should path unique filenames to the threads. >> >> Please, have a look at glpk-4.63/examples/threads. It shows how to >> handle GLPK errors in multithreaded applications. >> >> The example code creates one thread per problem. In a real world program >> you should use a thread pool. >> >> Best regards >> >> Heinrich Schuchardt >> >> >> On 08/30/2017 05:51 AM, Simone Atzeni wrote: >>> Hi all, >>> >>> thanks for your answers. >>> I updated to version 4.63, but I keep getting errors such as "segmentation >>> fault" or "glp_free: memory allocation error”. >>> >>> I have a function, with a few parameters in input, which creates the MIP >>> and solve it (attached the function which creates the MIP). >>> This function is called by multiple threads with different parameters and >>> they do not share any data. >>> As soon as I call the function within a mutex lock/unlock everything works >>> fine. >>> >>> I compiled the GLPK package with Clang/LLVM 4.9 which has support for TLS, >>> so I think everything should be fine. >>> Do I need to do something else to make GLPK thread safe? >>> >>> Thanks. >>> Best, >>> Simone > > ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
Hi Heinrich, you mean the line: std::string filename = "ilp_problem" + std::to_string(rand()) + ".lp”; or the problem name: glp_set_prob_name(mip, "overlap”); The filename is not used at all in the function, it was just something I forgot to remove. Thanks, Simone > On Aug 30, 2017, at 11:05, Heinrich Schuchardt wrote: > > Hello Simone, > > in your program all threads create random file names that are generated > from the same name space. The initial value of the random number > generator probably will be the same for all threads. This will lead to > two threads trying to write the same file. > > Either use a Singleton for the file name creation or use separate > namespaces by refering to the thread id like: > solution--counter.txt > > Your code lacks proper error handling for errors. > > You should path unique filenames to the threads. > > Please, have a look at glpk-4.63/examples/threads. It shows how to > handle GLPK errors in multithreaded applications. > > The example code creates one thread per problem. In a real world program > you should use a thread pool. > > Best regards > > Heinrich Schuchardt > > > On 08/30/2017 05:51 AM, Simone Atzeni wrote: >> Hi all, >> >> thanks for your answers. >> I updated to version 4.63, but I keep getting errors such as "segmentation >> fault" or "glp_free: memory allocation error”. >> >> I have a function, with a few parameters in input, which creates the MIP and >> solve it (attached the function which creates the MIP). >> This function is called by multiple threads with different parameters and >> they do not share any data. >> As soon as I call the function within a mutex lock/unlock everything works >> fine. >> >> I compiled the GLPK package with Clang/LLVM 4.9 which has support for TLS, >> so I think everything should be fine. >> Do I need to do something else to make GLPK thread safe? >> >> Thanks. >> Best, >> Simone ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
Hello Simone, in your program all threads create random file names that are generated from the same name space. The initial value of the random number generator probably will be the same for all threads. This will lead to two threads trying to write the same file. Either use a Singleton for the file name creation or use separate namespaces by refering to the thread id like: solution--counter.txt Your code lacks proper error handling for errors. You should path unique filenames to the threads. Please, have a look at glpk-4.63/examples/threads. It shows how to handle GLPK errors in multithreaded applications. The example code creates one thread per problem. In a real world program you should use a thread pool. Best regards Heinrich Schuchardt On 08/30/2017 05:51 AM, Simone Atzeni wrote: > Hi all, > > thanks for your answers. > I updated to version 4.63, but I keep getting errors such as "segmentation > fault" or "glp_free: memory allocation error”. > > I have a function, with a few parameters in input, which creates the MIP and > solve it (attached the function which creates the MIP). > This function is called by multiple threads with different parameters and > they do not share any data. > As soon as I call the function within a mutex lock/unlock everything works > fine. > > I compiled the GLPK package with Clang/LLVM 4.9 which has support for TLS, so > I think everything should be fine. > Do I need to do something else to make GLPK thread safe? > > Thanks. > Best, > Simone ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
Yes, I run the following command: "../configure --prefix=$HOME/usr --with-gmp” attached the output of “config”. I am working on a Red Hat Enterprise Linux Server release 7.3. Thanks. Simone ../configure --prefix=$HOME/usr --with-gmp checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/tce/bin/ld checking if the linker (/usr/tce/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 3458764513820540925 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/tce/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/tce/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for exp in -lm... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for gettimeofday... yes checking gmp.h usability... yes checking gmp.h presence... yes checking for gmp.h... yes checking whether to use GNU MP bignum library... yes checking whether to enable shared library support... no checking whether to enable MathProg ODBC support... no checking whether to enable MathProg MySQL support... no checking whether to enable reentrancy support... yes checking for thread local storage (TLS) class specifier... _Thread_local checking if libtool needs -no-undefined flag to build shared libraries... no checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating src/Makefile config.status: creating examples/Makefile config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands > On Aug 30, 2017, at 00:52, Andrew Makhorin wrote: > >> thanks for your answers. >> I updated to version 4.63, but I keep getting errors such as >> "segmentation fault" or "glp_free: memory allocation error”. >> >> I h
Re: [Help-glpk] Thread Safety of GLPK
> thanks for your answers. > I updated to version 4.63, but I keep getting errors such as > "segmentation fault" or "glp_free: memory allocation error”. > > I have a function, with a few parameters in input, which creates the > MIP and solve it (attached the function which creates the MIP). > This function is called by multiple threads with different parameters and > they do not share any data. > As soon as I call the function within a mutex lock/unlock everything works > fine. > > I compiled the GLPK package with Clang/LLVM 4.9 which has support for > TLS, so I think everything should be fine. > Do I need to do something else to make GLPK thread safe? > How do you configure the package? Do you run the configure script? ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
Hi all, thanks for your answers. I updated to version 4.63, but I keep getting errors such as "segmentation fault" or "glp_free: memory allocation error”. I have a function, with a few parameters in input, which creates the MIP and solve it (attached the function which creates the MIP). This function is called by multiple threads with different parameters and they do not share any data. As soon as I call the function within a mutex lock/unlock everything works fine. I compiled the GLPK package with Clang/LLVM 4.9 which has support for TLS, so I think everything should be fine. Do I need to do something else to make GLPK thread safe? Thanks. Best, Simone bool solve_mip(MyData *node1, struct MyData *node2) { glp_prob *mip; int ia[1+4], ja[1+4]; double ar[1+4], z, x1, x2, size1, size2; bool res = false; mip = glp_create_prob(); glp_set_prob_name(mip, "overlap"); glp_set_obj_dir(mip, GLP_MIN); glp_add_rows(mip, 1); glp_set_row_name(mip, 1, "c0"); long int diff = node1->start - node2->start; glp_set_row_bnds(mip, 1, GLP_FX, -1 * diff, -1 * diff); glp_add_cols(mip, 4); glp_set_col_name(mip, 1, "x1"); glp_set_col_bnds(mip, 1, GLP_DB, 0.0, node1->count); glp_set_obj_coef(mip, 1, node1->diff); glp_set_col_kind(mip, 1, GLP_IV); glp_set_col_name(mip, 2, "x2"); glp_set_col_bnds(mip, 2, GLP_DB, 0.0, node2->count); glp_set_obj_coef(mip, 2, node2->diff); glp_set_col_kind(mip, 2, GLP_IV); glp_set_col_name(mip, 3, "size1"); glp_set_col_bnds(mip, 3, GLP_DB, 0.0, (1 << (node1->size_type >> 4)) - 1); glp_set_col_kind(mip, 3, GLP_IV); glp_set_col_name(mip, 4, "size2"); glp_set_col_bnds(mip, 4, GLP_DB, 0.0, (1 << (node2->size_type >> 4)) - 1); glp_set_col_kind(mip, 4, GLP_IV); ia[1] = 1, ja[1] = 1, ar[1] = node1->diff; ia[2] = 1, ja[2] = 2, ar[2] = node2->diff; ar[2] *= -1; ia[3] = 1, ja[3] = 3, ar[3] = 1.0; ia[4] = 1, ja[4] = 4, ar[4] = -1.0; glp_load_matrix(mip, 4, ia, ja, ar); std::string filename = "ilp_problem" + std::to_string(rand()) + ".lp"; glp_iocp parm; glp_init_iocp(&parm); parm.presolve = GLP_ON; glp_term_out(GLP_OFF); glp_intopt(mip, &parm); int ret = glp_mip_status(mip); if(ret != GLP_NOFEAS) res = true; glp_delete_prob(mip); glp_free_env(); return res; } > On Aug 25, 2017, at 01:13, Andrew Makhorin wrote: > > >> In the GLPK documentation, paragraph "2.1.3 Thread Safety" states: >> >> >> "The standard version of GLPK API is not thread safe and therefore >> should not be used in multi-threaded programs.” > > The *standard* (i.e. ANSI C89) version is not thread safe. However, > starting from 4.61 (released on Jan 2017) glpk can be used in > multi-threaded programs on some platforms (including GNU/Linux and MS > Windows); for more details please see: > https://lists.gnu.org/archive/html/help-glpk/2017-01/msg00111.html . > (It's better to use the most recent version, which is 4.63.) ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
> In the GLPK documentation, paragraph "2.1.3 Thread Safety" states: > > > "The standard version of GLPK API is not thread safe and therefore > should not be used in multi-threaded programs.” The *standard* (i.e. ANSI C89) version is not thread safe. However, starting from 4.61 (released on Jan 2017) glpk can be used in multi-threaded programs on some platforms (including GNU/Linux and MS Windows); for more details please see: https://lists.gnu.org/archive/html/help-glpk/2017-01/msg00111.html . (It's better to use the most recent version, which is 4.63.) ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread Safety of GLPK
GLPK 4.63 supports multi threading. Is your citation from a current manual? Regards Heinrich Am 25.08.17, 05:52, Simone Atzeni schrieb: Hi,In the GLPK documentation, paragraph "2.1.3 Thread Safety" states:"The standard version of GLPK API is not thread safe and therefore should not be used in multi-threaded programs.”Does it mean that two threads can not solve two independent LP/MIP simultaneously?For example, I am running a multi-threaded program where each thread is solving a different MIP, and I am experiencing a segmentation fault.I tried to analyzed the problem with GDB and looks like the seg fault is happening when one thread free the memory of its own MIP.Could the non-thread safety be the reason of the segmentation fault?I put the function call that creates and solves the MIP within a mutex lock/unlock and the segmentation fault is not happening, so I guess that answers my question.But if that’s the reason, is there a workaround or thread-safe GLPK version?The mutex reduces heavily the performance of my program.Thanks.Best Regards,Simone Simone AtzeniPhD CandidateSchool of ComputingUniversity of Utah_mobile: +1 (801) 696-8373email: sim...@cs.utah.eduhttp://www.cs.utah.edu/~simone ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
I stumbled on the same problem as Mathieu: I wanted to run independent GLPK computations (separate problem objects) in different threads (these threads are started from OpenMP). My solution was to modify one line in tls.c: static _Thread_local void *tls = NULL; This is standard C2011 and supported by recent compilers. It seems older versions of gcc used __thread and Visual C++ supported __declspec(thread), both of which are still respectively supported. I was wondering whether some configure option could make its way into glpk so as to activate thread-local storage for the main platforms, since this seems a common request. -- David Monniaux Directeur de recherche au CNRS, laboratoire VERIMAG http://www-verimag.imag.fr/~monniaux/ ___ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> After several from-scratch attempts, I get the following (probably > simple) error from make LIBS=-lpthread: make[2]: > Entering directory `/home/lowasser/glpk-4.43/examples #39; > /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol > glpsol.o ../src/libglpk.la -lpthread > libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o > ../src/.libs/libglpk.so -lpthread > ../src/.libs/libglpk.so: undefined reference to `sqrt #39; > Try LIBS='-lm -lpthread' . This must work. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
On Fri, 23 Apr 2010, Louis Wasserman wrote: After several from-scratch attempts, I get the following (probably simple) error from make LIBS=-lpthread: make[2]: Entering directory `/home/lowasser/glpk-4.43/examples #39; /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol glpsol.o ../src/libglpk.la -lpthread I suspect that LIBS=-lpthread completely replaces the library list with a single library. LIBS+=-lpthread might work, but I'm not sure. -- Michael henne...@web.cs.ndsu.nodak.edu "Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be."___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
After several from-scratch attempts, I get the following (probably simple) error from make LIBS=-lpthread: make[2]: Entering directory `/home/lowasser/glpk-4.43/examples #39; /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol glpsol.o ../src/libglpk.la -lpthread libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o ../src/.libs/libglpk.so -lpthread ../src/.libs/libglpk.so: undefined reference to `sqrt #39; ../src/.libs/libglpk.so: undefined reference to `floor #39; ../src/.libs/libglpk.so: undefined reference to `ceil #39; ../src/.libs/libglpk.so: undefined reference to `log #39; ../src/.libs/libglpk.so: undefined reference to `atan #39; ../src/.libs/libglpk.so: undefined reference to `fmod #39; ../src/.libs/libglpk.so: undefined reference to `acos #39; ../src/.libs/libglpk.so: undefined reference to `exp #39; ../src/.libs/libglpk.so: undefined reference to `sin #39; ../src/.libs/libglpk.so: undefined reference to `pow #39; ../src/.libs/libglpk.so: undefined reference to `atan2 #39; ../src/.libs/libglpk.so: undefined reference to `cos #39; ../src/.libs/libglpk.so: undefined reference to `log10 #39; Bah, humbug. Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis On Thu, Apr 22, 2010 at 3:30 PM, Andrew Makhorin wrote: > Pthread_getspecific and pthread_setspecific are part of the pthread > library. On Linux you probably need to specify -lpthread along with > other options passed to gcc and libtool. > So, um, where/how do I put that in? make LIBS=-lpthread After several from-scratch attempts, I get the following (probably simple) error from make LIBS=-lpthread: make[2]: Entering directory `/home/lowasser/glpk-4.43/examples'/bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol glpsol.o ../src/libglpk.la -lpthread libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o ../src/.libs/libglpk.so -lpthread ../src/.libs/libglpk.so: undefined reference to `sqrt' ../src/.libs/libglpk.so: undefined reference to `floor' ../src/.libs/libglpk.so: undefined reference to `ceil' ../src/.libs/libglpk.so: undefined reference to `log' ../src/.libs/libglpk.so: undefined reference to `atan' ../src/.libs/libglpk.so: undefined reference to `fmod' ../src/.libs/libglpk.so: undefined reference to `acos' ../src/.libs/libglpk.so: undefined reference to `exp' ../src/.libs/libglpk.so: undefined reference to `sin' ../src/.libs/libglpk.so: undefined reference to `pow' ../src/.libs/libglpk.so: undefined reference to `atan2' ../src/.libs/libglpk.so: undefined reference to `cos' ../src/.libs/libglpk.so: undefined reference to `log10'Bah, humbug. Louis Wassermanwasserman.lo...@gmail.comhttp://profiles.google.com/wasserman.louis On Thu, Apr 22, 2010 at 3:30 PM, Andrew Makhorinwrote: > Pthread_getspecific and pthread_setspecific are part of the pthread > library. On Linux you probably need to specify -lpthread along with > other options passed to gcc and libtool. > So, um, where/how do I put that in? make LIBS=-lpthread ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> Pthread_getspecific and pthread_setspecific are part of the pthread > library. On Linux you probably need to specify -lpthread along with > other options passed to gcc and libtool. > So, um, where/how do I put that in? make LIBS=-lpthread ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> Let me put it more directly: > I replaced glpenv02.c with the version someone posted as being > thread-safe. ./configure worked fine, but make yielded: > /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol > glpsol.o ../src/libglpk.la -lm -L/usr/include/ > libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o > ../src/.libs/libglpk.so -L/usr/include/ -lm > ../src/.libs/libglpk.so: undefined reference to `pthread_getspecific #39; > ../src/.libs/libglpk.so: undefined reference to `pthread_setspecific #39; Pthread_getspecific and pthread_setspecific are part of the pthread library. On Linux you probably need to specify -lpthread along with other options passed to gcc and libtool. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
Let me put it more directly: I replaced glpenv02.c with the version someone posted as being thread-safe. ./configure worked fine, but make yielded: /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol glpsol.o ../src/libglpk.la -lm -L/usr/include/ libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o ../src/.libs/libglpk.so -L/usr/include/ -lm ../src/.libs/libglpk.so: undefined reference to `pthread_getspecific #39; ../src/.libs/libglpk.so: undefined reference to `pthread_setspecific #39; Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis On Wed, Apr 21, 2010 at 7:43 PM, Louis Wasserman wrote: Do I need to mess with the configure options to build with this modified glpenv02.c? Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis Let me put it more directly:I replaced glpenv02.c with the version someone posted as being thread-safe. ./configure worked fine, but make yielded:/bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol glpsol.o ../src/libglpk.la -lm -L/usr/include/ libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o ../src/.libs/libglpk.so -L/usr/include/ -lm../src/.libs/libglpk.so: undefined reference to `pthread_getspecific'../src/.libs/libglpk.so: undefined reference to `pthread_setspecific' Louis Wassermanwasserman.lo...@gmail.comhttp://profiles.google.com/wasserman.louis On Wed, Apr 21, 2010 at 7:43 PM, Louis Wassermanwrote: Do I need to mess with the configure options to build with this modified glpenv02.c?Louis Wassermanwasserman.lo...@gmail.comhttp://profiles.google.com/wasserman.louis ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
Do I need to mess with the configure options to build with this modified glpenv02.c? Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis Do I need to mess with the configure options to build with this modified glpenv02.c?Louis Wassermanwasserman.lo...@gmail.comhttp://profiles.google.com/wasserman.louis ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> Thank you Andrew for this feature which will be valuable for me as well! > I am using the java version of glpk, and I am wondering if it has > also been tested with multi-threads. What do I have to change in the > java or swig files in order to be able to take this into account? You need to replace file glpenv02.c in glpk with a reentrant version, for example, with that one I posted to the list. > For > example, where do I have to initialize the environment thread pointer? Somewhere before creating threads. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
Hi, Thank you Andrew for this feature which will be valuable for me as well! I am using the java version of glpk, and I am wondering if it has also been tested with multi-threads. What do I have to change in the java or swig files in order to be able to take this into account? For example, where do I have to initialize the environment thread pointer? Sylvain Fournier Date: Thu, 15 Apr 2010 14:06:15 +0400 > From: Andrew Makhorin > Subject: Re: [Help-glpk] Thread safety of GLPK > To: "Hammond, Paul" > Cc: help-glpk@gnu.org > Message-ID: <474395093.20100415140...@gnu.org> > Content-Type: text/plain; charset="us-ascii" > > > Thanks for this. If you find your old code, do send it over, we > > don't mind if it's not the standard release, if it works, we'll > > consider using it. > > Please see the attachment. > > You need to replace file glpenv02.c with a reentrant version and then > build the package as usual. Note that glpsol will not work, because it > does not create the thread-specific data key used in the reentrant > version of glpenv02.c. Mtsamp.c is an example program that works. > > Hope this helps. > > Andrew Makhorin > -- next part -- > /* glpenv02.c (thread local storage) */ > > /* (reserved for copyright notice) */ > > #include > #include "glpenv.h" > > /* re-enterable POSIX version */ > > pthread_key_t _glp_pth_key; > /* must be initialized in the main program */ > > void tls_set_ptr(void *ptr) > { pthread_setspecific(_glp_pth_key, ptr); > return; > } > > void *tls_get_ptr(void) > { void *ptr; > ptr = pthread_getspecific(_glp_pth_key); > return ptr; > } > > /* eof */ > -- next part -- > /* mtsamp.c */ > > /*** > * This is an example program which illustrates how to use GLPK API in > * multi-threaded application on POSIX platform. > * > * To run this program use the following command: > * > * mtsamp.exe mps-file-1 mps-file-2 ... mps-file-n > * > * Each mps file specified in the command line is processed by separate > * thread. > ***/ > > #include > #include > #include > #include > > void *solve_mps(void *arg) > { char *fname = arg; > glp_prob *P; > P = glp_create_prob(); > if (glp_read_mps(P, GLP_MPS_FILE, NULL, fname) != 0) > { fprintf(stderr, "Cannot read mps file `%s'\n", fname); > return NULL; > } > glp_simplex(P, NULL); > glp_delete_prob(P); > glp_free_env(); > return NULL; > } > > #define MAX_THREADS 20 > > extern pthread_key_t _glp_pth_key; > > int main(int argc, char *argv[]) > { pthread_t h[1+MAX_THREADS]; > int t, ret; > if (argc < 2) > { fprintf(stderr, "At least one mps file must be specified\n"); > exit(EXIT_FAILURE); > } > if (argc-1 > MAX_THREADS) > { fprintf(stderr, "Too many mps files\n"); > exit(EXIT_FAILURE); > } > ret = pthread_key_create(&_glp_pth_key, NULL); > if (ret != 0) > { fprintf(stderr, "Unable to create thread-specific key\n"); > exit(EXIT_FAILURE); > } > for (t = 1; t < argc; t++) > { ret = pthread_create(&h[t], NULL, solve_mps, argv[t]); > if (ret != 0) > { fprintf(stderr, "Unable to create thread for `%s'\n", > argv[t]); >exit(EXIT_FAILURE); > } > } > for (t = 1; t < argc; t++) > { ret = pthread_join(h[t], NULL); > if (ret != 0) > { fprintf(stderr, "Waiting failure for thread %d\n", t); >exit(EXIT_FAILURE); > } > } > fprintf(stderr, "GLPK multi-threaded DLL seems to work\n"); > return 0; > } > > /* eof */ > ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> Thanks for this. If you find your old code, do send it over, we > don't mind if it's not the standard release, if it works, we'll > consider using it. Please see the attachment. You need to replace file glpenv02.c with a reentrant version and then build the package as usual. Note that glpsol will not work, because it does not create the thread-specific data key used in the reentrant version of glpenv02.c. Mtsamp.c is an example program that works. Hope this helps. Andrew Makhorin/* glpenv02.c (thread local storage) */ /* (reserved for copyright notice) */ #include #include "glpenv.h" /* re-enterable POSIX version */ pthread_key_t _glp_pth_key; /* must be initialized in the main program */ void tls_set_ptr(void *ptr) { pthread_setspecific(_glp_pth_key, ptr); return; } void *tls_get_ptr(void) { void *ptr; ptr = pthread_getspecific(_glp_pth_key); return ptr; } /* eof */ /* mtsamp.c */ /*** * This is an example program which illustrates how to use GLPK API in * multi-threaded application on POSIX platform. * * To run this program use the following command: * * mtsamp.exe mps-file-1 mps-file-2 ... mps-file-n * * Each mps file specified in the command line is processed by separate * thread. ***/ #include #include #include #include void *solve_mps(void *arg) { char *fname = arg; glp_prob *P; P = glp_create_prob(); if (glp_read_mps(P, GLP_MPS_FILE, NULL, fname) != 0) { fprintf(stderr, "Cannot read mps file `%s'\n", fname); return NULL; } glp_simplex(P, NULL); glp_delete_prob(P); glp_free_env(); return NULL; } #define MAX_THREADS 20 extern pthread_key_t _glp_pth_key; int main(int argc, char *argv[]) { pthread_t h[1+MAX_THREADS]; int t, ret; if (argc < 2) { fprintf(stderr, "At least one mps file must be specified\n"); exit(EXIT_FAILURE); } if (argc-1 > MAX_THREADS) { fprintf(stderr, "Too many mps files\n"); exit(EXIT_FAILURE); } ret = pthread_key_create(&_glp_pth_key, NULL); if (ret != 0) { fprintf(stderr, "Unable to create thread-specific key\n"); exit(EXIT_FAILURE); } for (t = 1; t < argc; t++) { ret = pthread_create(&h[t], NULL, solve_mps, argv[t]); if (ret != 0) { fprintf(stderr, "Unable to create thread for `%s'\n", argv[t]); exit(EXIT_FAILURE); } } for (t = 1; t < argc; t++) { ret = pthread_join(h[t], NULL); if (ret != 0) { fprintf(stderr, "Waiting failure for thread %d\n", t); exit(EXIT_FAILURE); } } fprintf(stderr, "GLPK multi-threaded DLL seems to work\n"); return 0; } /* eof */ ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> I wonder if it would be feasible to re-implement this using the > posix threads API The main routine should call pthread_key_create to create a thread specific location used to store a pointer to the glpk environment block. The routine tls_set_ptr should call pthread_setspecific to store the pointer into the specific location, and the routine tls_get_ptr should call pthread_getspecific to retrieve the pointer from the specific location. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> ...but if you implement locking, then then you will have thread-safety > but not full concurrency (at least in the critical sections). You'd be > better off collecting all the non-sharable state in a structure that > that each thread creates and passes around as an extra function > parameter - i.e. make the code re-entrant (no locks) such that you > have true concurrency. Exactly this technique is used in glpk: all common variables are stored in the glpk environment block which is dynamically allocated by glp_init_env and deallocated by glp_free_env. However, a pointer to this block is stored in a static variable. > Andrew, that's pretty interesting - I thought it would have taken a > lot more work to make the code re-entrant, but seems like it's pretty > much there. > > I wonder if it would be feasible to re-implement this using the posix > threads API and then use this API adapter on Windows, such that the > re-entrant code would be portable across all platforms? It is possible. A while ago I implemented a reenterable version using posix threads (I will try to find the code); I don't remember, but there were some portability issues, so I decided not to include that version in the official glpk distribution. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
RE: [Help-glpk] Thread safety of GLPK
On Wed, 14 Apr 2010, Hammond, Paul wrote: So I guess I just don't mean thread safe, I mean thread hot, as in I can have multiple GLPK computations going in separate threads simultaneously which don't need to synchronize on anything or if they do, it's for a very small part of the computation rather than the entire duration. Instead of threads, you might consider processes. -- Michael henne...@web.cs.ndsu.nodak.edu "Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be." ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> Just to confirm my understanding, are you saying if I make the > changes you describe below, that as long as each call to the solver > referencing the GLPK data structure instances for a single LP problem > are made from the one thread, i.e. sequentially, I'm fine? Yes. Please see an implementation example: http://lists.gnu.org/archive/html/help-glpk/2009-12/msg8.html (note that the routine names were changed in v4.43; you need to change the glpenv02.c module). > I only run into thread safety issues if I were to create multiple > threads to make GLPK calls on the same LP problem. > In summary, one thread per LP problem is fine? As this is what I > want, I only need to be able to run X threads solving X LP problems, > one each concurrently to be at the MT level I require. > I do not require MT safe access to a single LP problem. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
Paul, > I'm thinking since it is written in C, and C is source compatible > with C++, since C++ does support locking in threads, if one was to > treat it as a C++ app written mostly in C, it may be possible to > multi-thread it without a huge rewrite? > I say this without any knowledge of the GLPK source at all or how > it works internally, so please bear my comments in that light, but in > terms of locking, if the data structures being used for each > computation are completely separate copies in each thread, I'm not > sure where the demand for locking arises, perhaps you could elaborate > a little? > To get thread safety now, I can synchronize access to the JNI lib > in Java to enforce single-threadness, but of course it means if I have > multiple computations wanting to use GLPK, which I do, they have to > queue for it and I have a central bottleneck. > So I guess I just don't mean thread safe, I mean thread hot, as in > I can have multiple GLPK computations going in separate threads > simultaneously which don't need to synchronize on anything or if they > do, it's for a very small part of the computation rather than the > entire duration. You may make glpk code reenterable by replacing the routines tls_set_ptr and tls_get_ptr in file glpenv02.c (v4.43) with a appropriate reentrant version. The variable tls (declared as static in the original non-reentrant version) is a pointer to the glpk environment. In the reentrant version it must be allocated in the thread local storage, i.e. each thread should have its own instance of that variable. This feature is not implemented in glpk due to portability issues. Please note that reenterability does not mean thread-safety, i.e. you can call glpk api routines from different threads, however, each problem object (glp_prob) can be used only in that thread where it was created. Andrew Makhorin ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
RE: [Help-glpk] Thread safety of GLPK
Yes, I was referred to separate C++ threading libraries that give you threading support in C++. Paul -Original Message- From: Michael Hennebry [mailto:henne...@web.cs.ndsu.nodak.edu] Sent: 14 April 2010 14:51 To: Hammond, Paul (IDEAS) Cc: help-glpk@gnu.org; Andrew Makhorin Subject: RE: [Help-glpk] Thread safety of GLPK On Wed, 14 Apr 2010, Hammond, Paul wrote: > I'm thinking since it is written in C, and C is source compatible with C++, > since C++ does support locking in threads, if one was to treat it as a C++ > app written mostly in C, it may be possible to multi-thread it without a huge > rewrite? C++ doesn't know about threads either. Perhaps you are thinking of some C++-only thread implementation? -- Michael henne...@web.cs.ndsu.nodak.edu "Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be." -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
RE: [Help-glpk] Thread safety of GLPK
On Wed, 14 Apr 2010, Hammond, Paul wrote: I'm thinking since it is written in C, and C is source compatible with C++, since C++ does support locking in threads, if one was to treat it as a C++ app written mostly in C, it may be possible to multi-thread it without a huge rewrite? C++ doesn't know about threads either. Perhaps you are thinking of some C++-only thread implementation? -- Michael henne...@web.cs.ndsu.nodak.edu "Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be." ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
RE: [Help-glpk] Thread safety of GLPK
Andrew. I'm thinking since it is written in C, and C is source compatible with C++, since C++ does support locking in threads, if one was to treat it as a C++ app written mostly in C, it may be possible to multi-thread it without a huge rewrite? I say this without any knowledge of the GLPK source at all or how it works internally, so please bear my comments in that light, but in terms of locking, if the data structures being used for each computation are completely separate copies in each thread, I'm not sure where the demand for locking arises, perhaps you could elaborate a little? To get thread safety now, I can synchronize access to the JNI lib in Java to enforce single-threadness, but of course it means if I have multiple computations wanting to use GLPK, which I do, they have to queue for it and I have a central bottleneck. So I guess I just don't mean thread safe, I mean thread hot, as in I can have multiple GLPK computations going in separate threads simultaneously which don't need to synchronize on anything or if they do, it's for a very small part of the computation rather than the entire duration. Thx. Paul -Original Message- From: Andrew Makhorin [mailto:m...@gnu.org] Sent: 13 April 2010 20:05 To: Hammond, Paul (IDEAS) Cc: help-glpk@gnu.org Subject: Re: [Help-glpk] Thread safety of GLPK > I #8217;d like to know if GLPK (the C lib) is not thread > safe? No, glpk is not thread safe. > If not, are there any plans to ever make it thread safe? We get > occasional core dumps in a multi-threaded environment which we think are > related to thread safety as we get a SIGSEGV inside GLPK. Thread safety (unlike re-enterability) requires locking/unlocking program objects used by concurrent threads. Since the standard C does not provide such a feature, there are no plans in this direction. I'm just wondering how you would use glpk if it were thread safe? Thanks. Andrew Makhorin -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
> I #8217;d like to know if GLPK (the C lib) is not thread > safe? No, glpk is not thread safe. > If not, are there any plans to ever make it thread safe? We get > occasional core dumps in a multi-threaded environment which we think are > related to thread safety as we get a SIGSEGV inside GLPK. Thread safety (unlike re-enterability) requires locking/unlocking program objects used by concurrent threads. Since the standard C does not provide such a feature, there are no plans in this direction. I'm just wondering how you would use glpk if it were thread safe? Thanks. Andrew Makhorin ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
Hello Paul, > I'd like to know if GLPK (the C lib) is not thread > safe? Request for thread safety have been recurring: http://lists.gnu.org/archive/html/help-glpk/2002-08/msg00011.html http://lists.gnu.org/archive/html/help-glpk/2003-10/msg00020.html http://lists.gnu.org/archive/html/help-glpk/2005-04/msg00027.html http://lists.gnu.org/archive/html/help-glpk/2007-08/msg00040.html http://lists.gnu.org/archive/html/help-glpk/2009-03/msg00049.html http://lists.gnu.org/archive/html/help-glpk/2009-07/msg0.html Please, read the thread starting at http://lists.gnu.org/archive/html/help-glpk/2009-07/msg0.html It indicates some of the areas that make GLPK not threadsafe. Best regards Xypron -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Thread safety of GLPK
On Tue, 13 Apr 2010, Hammond, Paul wrote: I #8217;d like to know if GLPK (the C lib) is not thread safe? If not, are there any plans to ever make it thread safe? We get occasional core dumps in a multi-threaded environment which we think are related to thread safety as we get a SIGSEGV inside GLPK. GLPK is not thread-safe. What you might do is dedicate a thread to GLPK. Communicate through messages. -- Michael henne...@web.cs.ndsu.nodak.edu "Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be." ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk