Re: [Help-glpk] Thread Safety of GLPK

[Heinrich Schuchardt]

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

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

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

Re: [Help-glpk] Thread Safety of GLPK

[Heinrich Schuchardt]

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

Re: [Help-glpk] Questions regarding Simplex during Integer Optimization

[Andrew Makhorin]

> I want to set overall simplex parameters for an integer (linear)
> optimization. I am little bit confused, that I “only” can use
> glp_simplex (where I can set parameters like pricing, meth, etc.)
> prior to the integer optimization. But then the MILP has no presolve
> option and I seems that the simplex with standard settings (as far as
> I can interpret the code/output) is applied during branch-and-cut. The
> documentation doesn’t tell me more details about that.

> So, I thought to ask community for some explanation. Did it get the
> situation right and might there be future enhancements? I am not a
> native c developer, but after I inspected the code a little bit, it
> might be possible to pass a smcp optionally also to integer
> optimization or make parts of the parameters (at least meth, pricing)
> to be available through iocp. I could imagine an overall performance
> jump if dual simplex can be fully used during integer optimization for
> a variety of models.

In the mip solver the simplex solver is used internally and, strictly
speaking, it is not available to the user. For example, the presolve
option normally used in the simplex solver should not be used on
reoptimization performed by the mip solver, because: i) it would be
inefficient; ii) the mip solver has an internal presolver for this
purpose. Of course, some options could be specified in iocp to pass to
the simplex solver, but currently there is no need in that. Please note
also that both the simplex and mip solvers are still under development.



___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk