Re: [Help-glpk] Thread Safety of GLPK

[Heinrich Schuchardt]

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