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 <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