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 <xypron.g...@gmx.de> 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 <xypron.g...@gmx.de> 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-<thread_id>-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