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
>
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
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
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
> 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
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
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
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
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
___
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
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 replace
do I
have to initialize the environment thread pointer?
Sylvain Fournier
Date: Thu, 15 Apr 2010 14:06:15 +0400
From: Andrew Makhorin m...@gnu.org
Subject: Re: [Help-glpk] Thread safety of GLPK
To: Hammond, Paul paul.hamm...@morganstanley.com
Cc: help-glpk@gnu.org
Message-ID
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, are there any plans to ever make it thread
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++
: [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 multi-thread
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 GLPK
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
...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.e.
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
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
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.
22 matches
Mail list logo
