Re: [Help-glpk] Thread Safety of GLPK

[Simone Atzeni]

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 <address@hidden> 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 <address@hidden> 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
>> 
>>