help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] Thread Safety of GLPK


From: Heinrich Schuchardt
Subject: Re: [Help-glpk] Thread Safety of GLPK
Date: Wed, 30 Aug 2017 20:20:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]