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
> comp
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!
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 somethi
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.
Thanks,
Simone
> On Aug 30, 2017, at 11:
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 f
Yes, I run the following command:
"../configure --prefix=$HOME/usr --with-gmp”
attached the output of “config”.
I am working on a Red Hat Enterprise Linux Server release 7.3.
Thanks.
Simone
../configure --prefix=$HOME/usr --with-gmp
checking for a BSD-compatible install... /usr/bin/install -c
> 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
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 fu
> In the GLPK documentation, paragraph "2.1.3 Thread Safety" states:
>
>
> "The standard version of GLPK API is not thread safe and therefore
> should not be used in multi-threaded programs.”
The *standard* (i.e. ANSI C89) version is not thread safe. However,
starting from 4.61 (released on Jan
GLPK 4.63 supports multi threading.
Is your citation from a current manual?
Regards
Heinrich
Am 25.08.17, 05:52, Simone Atzeni schrieb:
Hi,In the GLPK documentation, paragraph "2.1.3 Thread Safety" states:"The standard version of GLPK API is not thread safe and therefore should not be used in m
I stumbled on the same problem as Mathieu: I wanted to run independent
GLPK computations (separate problem objects) in different threads (these
threads are started from OpenMP).
My solution was to modify one line in tls.c:
static _Thread_local void *tls = NULL;
This is standard C2011 and support
> After several from-scratch attempts, I get the following (probably
> simple) error from make LIBS=-lpthread: make[2]:
> Entering directory `/home/lowasser/glpk-4.43/examples #39;
> /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol
> glpsol.o ../src/libglpk.la
On Fri, 23 Apr 2010, Louis Wasserman wrote:
After several from-scratch attempts, I get the following (probably simple)
error from make LIBS=-lpthread: make[2]: Entering directory
`/home/lowasser/glpk-4.43/examples #39;
/bin/bash ../libtool --tag=CC --mode=link gcc -g -O2
After several from-scratch attempts, I get the following (probably simple)
error from make LIBS=-lpthread: make[2]: Entering directory
`/home/lowasser/glpk-4.43/examples #39;
/bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol glpsol.o
../src/libglpk.la -lpthr
> Pthread_getspecific and pthread_setspecific are part of the pthread
> library. On Linux you probably need to specify -lpthread along with
> other options passed to gcc and libtool.
> So, um, where/how do I put that in?
make LIBS=-lpthread
___
Help
> Let me put it more directly:
> I replaced glpenv02.c with the version someone posted as being
> thread-safe. ./configure worked fine, but make yielded:
> /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol
> glpsol.o ../src/libglpk.la -lm -L/usr/include/
> libtool: link: gcc -
Let me put it more directly:
I replaced glpenv02.c with the version someone posted as being thread-safe.
./configure worked fine, but make yielded:
/bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o glpsol glpsol.o
../src/libglpk.la -lm -L/usr/include/
libtool: link: gcc -g -O2
Do I need to mess with the configure options to build with this modified
glpenv02.c?
Louis Wasserman
wasserman.lo...@gmail.com
http://profiles.google.com/wasserman.louis
Do I need to mess with the configure options to build with this modified glpenv02.c?Louis Wassermanwasserman.lo...@gmail.co
> Thank you Andrew for this feature which will be valuable for me as well!
> I am using the java version of glpk, and I am wondering if it has
> also been tested with multi-threads. What do I have to change in the
> java or swig files in order to be able to take this into account?
You need to repl
do I
have to initialize the environment thread pointer?
Sylvain Fournier
Date: Thu, 15 Apr 2010 14:06:15 +0400
> From: Andrew Makhorin
> Subject: Re: [Help-glpk] Thread safety of GLPK
> To: "Hammond, Paul"
> Cc: help-glpk@gnu.org
> Message-ID: <474395093.2010041514
> Thanks for this. If you find your old code, do send it over, we
> don't mind if it's not the standard release, if it works, we'll
> consider using it.
Please see the attachment.
You need to replace file glpenv02.c with a reentrant version and then
build the package as usual. Note that glpsol wi
> I wonder if it would be feasible to re-implement this using the
> posix threads API
The main routine should call pthread_key_create to create a thread
specific location used to store a pointer to the glpk environment
block. The routine tls_set_ptr should call pthread_setspecific to
store the poi
> ...but if you implement locking, then then you will have thread-safety
> but not full concurrency (at least in the critical sections). You'd be
> better off collecting all the non-sharable state in a structure that
> that each thread creates and passes around as an extra function
> parameter - i.
On Wed, 14 Apr 2010, Hammond, Paul wrote:
So I guess I just don't mean thread safe, I mean thread hot, as in I can have
multiple GLPK computations going in separate threads simultaneously which don't
need to synchronize on anything or if they do, it's for a very small part of
the computation
> Just to confirm my understanding, are you saying if I make the
> changes you describe below, that as long as each call to the solver
> referencing the GLPK data structure instances for a single LP problem
> are made from the one thread, i.e. sequentially, I'm fine?
Yes. Please see an implementat
Paul,
> I'm thinking since it is written in C, and C is source compatible
> with C++, since C++ does support locking in threads, if one was to
> treat it as a C++ app written mostly in C, it may be possible to
> multi-thread it without a huge rewrite?
> I say this without any knowledge of the GLP
: [Help-glpk] Thread safety of GLPK
On Wed, 14 Apr 2010, Hammond, Paul wrote:
> I'm thinking since it is written in C, and C is source compatible with C++,
> since C++ does support locking in threads, if one was to treat it as a C++
> app written mostly in C, it may be possible to m
On Wed, 14 Apr 2010, Hammond, Paul wrote:
I'm thinking since it is written in C, and C is source compatible with C++,
since C++ does support locking in threads, if one was to treat it as a C++ app
written mostly in C, it may be possible to multi-thread it without a huge
rewrite?
C++ doesn't
Message-
From: Andrew Makhorin [mailto:m...@gnu.org]
Sent: 13 April 2010 20:05
To: Hammond, Paul (IDEAS)
Cc: help-glpk@gnu.org
Subject: Re: [Help-glpk] Thread safety of GLPK
> I #8217;d like to know if GLPK (the C lib) is not thread
> safe?
No, glpk is not thread safe.
> If not, a
> I #8217;d like to know if GLPK (the C lib) is not thread
> safe?
No, glpk is not thread safe.
> If not, are there any plans to ever make it thread safe? We get
> occasional core dumps in a multi-threaded environment which we think are
> related to thread safety as we get a SIGSEGV inside GLPK.
Hello Paul,
> I'd like to know if GLPK (the C lib) is not thread
> safe?
Request for thread safety have been recurring:
http://lists.gnu.org/archive/html/help-glpk/2002-08/msg00011.html
http://lists.gnu.org/archive/html/help-glpk/2003-10/msg00020.html
http://lists.gnu.org/archive/html/help-glpk/2
On Tue, 13 Apr 2010, Hammond, Paul wrote:
I #8217;d like to know if GLPK (the C lib) is not thread
safe? If not, are there any plans to ever make it thread safe? We get
occasional core dumps in a multi-threaded environment which we think are
related to thread safety as we get a SIGSEGV inside GL
32 matches
Mail list logo
