[Top][All Lists]

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

Re: [Help-glpk] Thread Safety of GLPK

From: Simone Atzeni
Subject: Re: [Help-glpk] Thread Safety of GLPK
Date: Wed, 30 Aug 2017 11:23:42 -0600

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.


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