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

[Simone Atzeni]

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: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] Thread Safety of GLPK

[Simone Atzeni]

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
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/tce/bin/ld
checking if the linker (/usr/tce/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 3458764513820540925
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to 
x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain 
format... func_convert_file_noop
checking for /usr/tce/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/tce/bin/ld -m elf_x86_64) supports shared 
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for exp in -lm... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for gettimeofday... yes
checking gmp.h usability... yes
checking gmp.h presence... yes
checking for gmp.h... yes
checking whether to use GNU MP bignum library... yes
checking whether to enable shared library support... no
checking whether to enable MathProg ODBC support... no
checking whether to enable MathProg MySQL support... no
checking whether to enable reentrancy support... yes
checking for thread local storage (TLS) class specifier... _Thread_local
checking if libtool needs -no-undefined flag to build shared libraries... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating src/Makefile
config.status: creating examples/Makefile
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
> On Aug 30, 2017, at 00:52, Andrew Makhorin  wrote:
> 
>> 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 h

Re: [Help-glpk] Thread Safety of GLPK

[Andrew Makhorin]

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

How do you configure the package? Do you run the configure script?



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

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

bool solve_mip(MyData *node1, struct MyData *node2) {
  glp_prob *mip;
  int ia[1+4], ja[1+4];
  double ar[1+4], z, x1, x2, size1, size2;
  bool res = false;

  mip = glp_create_prob();
  glp_set_prob_name(mip, "overlap");
  glp_set_obj_dir(mip, GLP_MIN);
  glp_add_rows(mip, 1);
  glp_set_row_name(mip, 1, "c0");
  long int diff = node1->start - node2->start;
  glp_set_row_bnds(mip, 1, GLP_FX, -1 * diff, -1 * diff);
  glp_add_cols(mip, 4);
  glp_set_col_name(mip, 1, "x1");
  glp_set_col_bnds(mip, 1, GLP_DB, 0.0, node1->count);
  glp_set_obj_coef(mip, 1, node1->diff);
  glp_set_col_kind(mip, 1, GLP_IV);
  glp_set_col_name(mip, 2, "x2");
  glp_set_col_bnds(mip, 2, GLP_DB, 0.0, node2->count);
  glp_set_obj_coef(mip, 2, node2->diff);
  glp_set_col_kind(mip, 2, GLP_IV);
  glp_set_col_name(mip, 3, "size1");
  glp_set_col_bnds(mip, 3, GLP_DB, 0.0, (1 << (node1->size_type >> 4)) - 1);
  glp_set_col_kind(mip, 3, GLP_IV);
  glp_set_col_name(mip, 4, "size2");
  glp_set_col_bnds(mip, 4, GLP_DB, 0.0, (1 << (node2->size_type >> 4)) - 1);
  glp_set_col_kind(mip, 4, GLP_IV);
  ia[1] = 1, ja[1] = 1, ar[1] = node1->diff;
  ia[2] = 1, ja[2] = 2, ar[2] = node2->diff; ar[2] *= -1;
  ia[3] = 1, ja[3] = 3, ar[3] = 1.0;
  ia[4] = 1, ja[4] = 4, ar[4] = -1.0;
  glp_load_matrix(mip, 4, ia, ja, ar);
  std::string filename = "ilp_problem" + std::to_string(rand()) + ".lp";
  glp_iocp parm;
  glp_init_iocp(&parm);
  parm.presolve = GLP_ON;
  glp_term_out(GLP_OFF);
  glp_intopt(mip, &parm);
  int ret = glp_mip_status(mip);
  if(ret != GLP_NOFEAS)
res = true;
  glp_delete_prob(mip);
  glp_free_env();

  return res;
}

> On Aug 25, 2017, at 01:13, Andrew Makhorin  wrote:
> 
> 
>> 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 2017) glpk can be used in
> multi-threaded programs on some platforms (including GNU/Linux and MS
> Windows); for more details please see:
> https://lists.gnu.org/archive/html/help-glpk/2017-01/msg00111.html .
> (It's better to use the most recent version, which is 4.63.)

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

Re: [Help-glpk] Thread Safety of GLPK

[Andrew Makhorin]

> 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 2017) glpk can be used in
multi-threaded programs on some platforms (including GNU/Linux and MS
Windows); for more details please see:
https://lists.gnu.org/archive/html/help-glpk/2017-01/msg00111.html .
(It's better to use the most recent version, which is 4.63.)




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

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 multi-threaded programs.”Does it mean that two threads can not solve two independent LP/MIP simultaneously?For example, I am running a multi-threaded program where each thread is solving a different MIP, and I am experiencing a segmentation fault.I tried to analyzed the problem with GDB and looks like the seg fault is happening when one thread free the memory of its own MIP.Could the non-thread safety be the reason of the segmentation fault?I put the function call that creates and solves the MIP within a mutex lock/unlock and the segmentation fault is not happening, so I guess that answers my question.But if that’s the reason, is there a workaround or  thread-safe GLPK version?The mutex reduces heavily the performance of my program.Thanks.Best Regards,Simone
Simone AtzeniPhD CandidateSchool of ComputingUniversity of Utah_mobile: +1 (801) 696-8373email: sim...@cs.utah.eduhttp://www.cs.utah.edu/~simone

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


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

[Help-glpk] Thread Safety of GLPK

[Simone Atzeni]

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 multi-threaded programs.”

Does it mean that two threads can not solve two independent LP/MIP 
simultaneously?
For example, I am running a multi-threaded program where each thread is solving 
a different MIP, and I am experiencing a segmentation fault.
I tried to analyzed the problem with GDB and looks like the seg fault is 
happening when one thread free the memory of its own MIP.

Could the non-thread safety be the reason of the segmentation fault?

I put the function call that creates and solves the MIP within a mutex 
lock/unlock and the segmentation fault is not happening, so I guess that 
answers my question.
But if that’s the reason, is there a workaround or  thread-safe GLPK version?
The mutex reduces heavily the performance of my program.

Thanks.
Best Regards,
Simone

Simone Atzeni
PhD Candidate
School of Computing
University of Utah
_
mobile: +1 (801) 696-8373
email: sim...@cs.utah.edu 
http://www.cs.utah.edu/~simone 

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

Re: [Help-glpk] Thread safety of GLPK

[David Monniaux]

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 supported by recent compilers.

It seems older versions of gcc used __thread and Visual C++ supported
__declspec(thread), both of which are still respectively supported.

I was wondering whether some configure option could make its way into
glpk so as to activate thread-local storage for the main platforms,
since this seems a common request.

-- 
David Monniaux
Directeur de recherche au CNRS, laboratoire VERIMAG
http://www-verimag.imag.fr/~monniaux/



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

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

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

> libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o
>  ../src/.libs/libglpk.so -lpthread                   

> ../src/.libs/libglpk.so: undefined reference to `sqrt #39;        
>                                          

Try LIBS='-lm -lpthread' . This must work.



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

Re: [Help-glpk] Thread safety of GLPK

[Michael Hennebry]

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   -o glpsol glpsol.o 
../src/libglpk.la -lpthread


I suspect that LIBS=-lpthread completely replaces
the library list with a single library.
LIBS+=-lpthread might work, but I'm not sure.

--
Michael   henne...@web.cs.ndsu.nodak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."___
Help-glpk mailing list
Help-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Thread safety of GLPK

[Louis Wasserman]

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

libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o  ../src/.libs/libglpk.so 
-lpthread                   

../src/.libs/libglpk.so: undefined reference to `sqrt #39;                      
                            

../src/.libs/libglpk.so: undefined reference to `floor #39;                     
                            

../src/.libs/libglpk.so: undefined reference to `ceil #39;                      
                            

../src/.libs/libglpk.so: undefined reference to `log #39;                       
                            

../src/.libs/libglpk.so: undefined reference to `atan #39;                      
                            

../src/.libs/libglpk.so: undefined reference to `fmod #39;                      
                            

../src/.libs/libglpk.so: undefined reference to `acos #39;                      
                            

../src/.libs/libglpk.so: undefined reference to `exp #39;                       
                            

../src/.libs/libglpk.so: undefined reference to `sin #39;                       
                            

../src/.libs/libglpk.so: undefined reference to `pow #39;                       
                            

../src/.libs/libglpk.so: undefined reference to `atan2 #39;                     
                            

../src/.libs/libglpk.so: undefined reference to `cos #39;                       
                            

../src/.libs/libglpk.so: undefined reference to `log10 #39;




Bah, humbug.







Louis Wasserman
wasserman.lo...@gmail.com
http://profiles.google.com/wasserman.louis


On Thu, Apr 22, 2010 at 3:30 PM, Andrew Makhorin  wrote:


> 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











 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'/bin/bash ../libtool --tag=CC   --mode=link gcc  -g -O2   -o glpsol glpsol.o ../src/libglpk.la -lpthread

libtool: link: gcc -g -O2 -o .libs/glpsol glpsol.o  ../src/.libs/libglpk.so -lpthread                   ../src/.libs/libglpk.so: undefined reference to `sqrt'                                                  

../src/.libs/libglpk.so: undefined reference to `floor'                                                 ../src/.libs/libglpk.so: undefined reference to `ceil'                                                  

../src/.libs/libglpk.so: undefined reference to `log'                                                   ../src/.libs/libglpk.so: undefined reference to `atan'                                                  

../src/.libs/libglpk.so: undefined reference to `fmod'                                                  ../src/.libs/libglpk.so: undefined reference to `acos'                                                  

../src/.libs/libglpk.so: undefined reference to `exp'                                                   ../src/.libs/libglpk.so: undefined reference to `sin'                                                   

../src/.libs/libglpk.so: undefined reference to `pow'                                                   ../src/.libs/libglpk.so: undefined reference to `atan2'                                                 

../src/.libs/libglpk.so: undefined reference to `cos'                                                   ../src/.libs/libglpk.so: undefined reference to `log10'Bah, humbug.

Louis Wassermanwasserman.lo...@gmail.comhttp://profiles.google.com/wasserman.louis


On Thu, Apr 22, 2010 at 3:30 PM, Andrew Makhorin  wrote:

> 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-glpk mailing list
Help-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> 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-glpk mailing list
Help-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> 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 -o .libs/glpsol glpsol.o
>  ../src/.libs/libglpk.so -L/usr/include/ -lm

> ../src/.libs/libglpk.so: undefined reference to `pthread_getspecific #39;

> ../src/.libs/libglpk.so: undefined reference to `pthread_setspecific #39;

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.





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

Re: [Help-glpk] Thread safety of GLPK

[Louis Wasserman]

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 -o .libs/glpsol glpsol.o  ../src/.libs/libglpk.so 
-L/usr/include/ -lm

../src/.libs/libglpk.so: undefined reference to `pthread_getspecific #39;

../src/.libs/libglpk.so: undefined reference to `pthread_setspecific #39;







Louis Wasserman
wasserman.lo...@gmail.com
http://profiles.google.com/wasserman.louis


On Wed, Apr 21, 2010 at 7:43 PM, Louis Wasserman  
wrote:
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









 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 -o .libs/glpsol glpsol.o  ../src/.libs/libglpk.so -L/usr/include/ -lm../src/.libs/libglpk.so: undefined reference to `pthread_getspecific'../src/.libs/libglpk.so: undefined reference to `pthread_setspecific'

Louis Wassermanwasserman.lo...@gmail.comhttp://profiles.google.com/wasserman.louis


On Wed, Apr 21, 2010 at 7:43 PM, Louis Wasserman  wrote:

Do I need to mess with the configure options to build with this modified glpenv02.c?Louis Wassermanwasserman.lo...@gmail.comhttp://profiles.google.com/wasserman.louis





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

Re: [Help-glpk] Thread safety of GLPK

[Louis Wasserman]

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.comhttp://profiles.google.com/wasserman.louis



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

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> 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 file glpenv02.c in glpk with a reentrant version,
for example, with that one I posted to the list.

>  For
> example, where do I have to initialize the environment thread pointer?

Somewhere before creating threads.





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

Re: [Help-glpk] Thread safety of GLPK

[Sylvain Fournier]

Hi,

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? For example, where 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.20100415140...@gnu.org>
> Content-Type: text/plain; charset="us-ascii"
>
> > 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 will not work, because it
> does not create the thread-specific data key used in the reentrant
> version of glpenv02.c. Mtsamp.c is an example program that works.
>
> Hope this helps.
>
> Andrew Makhorin
> -- next part --
> /* glpenv02.c (thread local storage) */
>
> /* (reserved for copyright notice) */
>
> #include 
> #include "glpenv.h"
>
> /* re-enterable POSIX version */
>
> pthread_key_t _glp_pth_key;
> /* must be initialized in the main program */
>
> void tls_set_ptr(void *ptr)
> { pthread_setspecific(_glp_pth_key, ptr);
>  return;
> }
>
> void *tls_get_ptr(void)
> { void *ptr;
>  ptr = pthread_getspecific(_glp_pth_key);
>  return ptr;
> }
>
> /* eof */
> -- next part --
> /* mtsamp.c */
>
> /***
> *  This is an example program which illustrates how to use GLPK API in
> *  multi-threaded application on POSIX platform.
> *
> *  To run this program use the following command:
> *
> * mtsamp.exe mps-file-1 mps-file-2 ... mps-file-n
> *
> *  Each mps file specified in the command line is processed by separate
> *  thread.
> ***/
>
> #include 
> #include 
> #include 
> #include 
>
> void *solve_mps(void *arg)
> { char *fname = arg;
>  glp_prob *P;
>  P = glp_create_prob();
>  if (glp_read_mps(P, GLP_MPS_FILE, NULL, fname) != 0)
>  {  fprintf(stderr, "Cannot read mps file `%s'\n", fname);
> return NULL;
>  }
>  glp_simplex(P, NULL);
>  glp_delete_prob(P);
>  glp_free_env();
>  return NULL;
> }
>
> #define MAX_THREADS 20
>
> extern pthread_key_t _glp_pth_key;
>
> int main(int argc, char *argv[])
> { pthread_t h[1+MAX_THREADS];
>  int t, ret;
>  if (argc < 2)
>  {  fprintf(stderr, "At least one mps file must be specified\n");
> exit(EXIT_FAILURE);
>  }
>  if (argc-1 > MAX_THREADS)
>  {  fprintf(stderr, "Too many mps files\n");
> exit(EXIT_FAILURE);
>  }
>  ret = pthread_key_create(&_glp_pth_key, NULL);
>  if (ret != 0)
>  {  fprintf(stderr, "Unable to create thread-specific key\n");
> exit(EXIT_FAILURE);
>  }
>  for (t = 1; t < argc; t++)
>  {  ret = pthread_create(&h[t], NULL, solve_mps, argv[t]);
> if (ret != 0)
> {  fprintf(stderr, "Unable to create thread for `%s'\n",
>   argv[t]);
>exit(EXIT_FAILURE);
> }
>  }
>  for (t = 1; t < argc; t++)
>  {  ret = pthread_join(h[t], NULL);
> if (ret != 0)
> {  fprintf(stderr, "Waiting failure for thread %d\n", t);
>exit(EXIT_FAILURE);
> }
>  }
>  fprintf(stderr, "GLPK multi-threaded DLL seems to work\n");
>  return 0;
> }
>
> /* eof */
>
___
Help-glpk mailing list
Help-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> 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 will not work, because it
does not create the thread-specific data key used in the reentrant
version of glpenv02.c. Mtsamp.c is an example program that works.

Hope this helps.

Andrew Makhorin/* glpenv02.c (thread local storage) */

/* (reserved for copyright notice) */

#include 
#include "glpenv.h"

/* re-enterable POSIX version */

pthread_key_t _glp_pth_key;
/* must be initialized in the main program */

void tls_set_ptr(void *ptr)
{ pthread_setspecific(_glp_pth_key, ptr);
  return;
}

void *tls_get_ptr(void)
{ void *ptr;
  ptr = pthread_getspecific(_glp_pth_key);
  return ptr;
}

/* eof */
/* mtsamp.c */

/***
*  This is an example program which illustrates how to use GLPK API in
*  multi-threaded application on POSIX platform.
*
*  To run this program use the following command:
*
* mtsamp.exe mps-file-1 mps-file-2 ... mps-file-n
*
*  Each mps file specified in the command line is processed by separate
*  thread.
***/

#include 
#include 
#include 
#include 

void *solve_mps(void *arg)
{ char *fname = arg;
  glp_prob *P;
  P = glp_create_prob();
  if (glp_read_mps(P, GLP_MPS_FILE, NULL, fname) != 0)
  {  fprintf(stderr, "Cannot read mps file `%s'\n", fname);
 return NULL;
  }
  glp_simplex(P, NULL);
  glp_delete_prob(P);
  glp_free_env();
  return NULL;
}

#define MAX_THREADS 20

extern pthread_key_t _glp_pth_key;

int main(int argc, char *argv[])
{ pthread_t h[1+MAX_THREADS];
  int t, ret;
  if (argc < 2)
  {  fprintf(stderr, "At least one mps file must be specified\n");
 exit(EXIT_FAILURE);
  }
  if (argc-1 > MAX_THREADS)
  {  fprintf(stderr, "Too many mps files\n");
 exit(EXIT_FAILURE);
  }
  ret = pthread_key_create(&_glp_pth_key, NULL);
  if (ret != 0)
  {  fprintf(stderr, "Unable to create thread-specific key\n");
 exit(EXIT_FAILURE);
  }
  for (t = 1; t < argc; t++)
  {  ret = pthread_create(&h[t], NULL, solve_mps, argv[t]);
 if (ret != 0)
 {  fprintf(stderr, "Unable to create thread for `%s'\n",
   argv[t]);
exit(EXIT_FAILURE);
 }
  }
  for (t = 1; t < argc; t++)
  {  ret = pthread_join(h[t], NULL);
 if (ret != 0)
 {  fprintf(stderr, "Waiting failure for thread %d\n", t);
exit(EXIT_FAILURE);
 }
  }
  fprintf(stderr, "GLPK multi-threaded DLL seems to work\n");
  return 0;
}

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

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> 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 pointer into the specific location, and the routine
tls_get_ptr should call pthread_getspecific to retrieve the pointer
from the specific location.




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

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> ...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. make the code re-entrant (no locks) such that you
> have true concurrency.

Exactly this technique is used in glpk: all common variables are
stored in the glpk environment block which is dynamically allocated
by glp_init_env and deallocated by glp_free_env. However, a pointer
to this block is stored in a static variable.

> Andrew, that's pretty interesting - I thought it would have taken a
> lot more work to make the code re-entrant, but seems like it's pretty
> much there.
> 
> I wonder if it would be feasible to re-implement this using the posix
> threads API and then use this API adapter on Windows, such that the
> re-entrant code would be portable across all platforms?

It is possible. A while ago I implemented a reenterable version
using posix threads (I will try to find the code); I don't remember,
but there were some portability issues, so I decided not to include
that version in the official glpk distribution.



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

RE: [Help-glpk] Thread safety of GLPK

[Michael Hennebry]

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 rather than the entire duration.


Instead of threads, you might consider processes.

--
Michael   henne...@web.cs.ndsu.nodak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."


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

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

> 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 implementation example:

http://lists.gnu.org/archive/html/help-glpk/2009-12/msg8.html

(note that the routine names were changed in v4.43; you need to
change the glpenv02.c module).

> I only run into thread safety issues if I were to create multiple
> threads to make GLPK calls on the same LP problem.

> In summary, one thread per LP problem is fine? As this is what I
> want, I only need to be able to run X threads solving X LP problems,
> one each concurrently to be at the MT level I require.

> I do not require MT safe access to a single LP problem.





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

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

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 source at all or how
> it works internally, so please bear my comments in that light, but in
> terms of locking, if the data structures being used for each
> computation are completely separate copies in each thread, I'm not
> sure where the demand for locking arises, perhaps you could elaborate
> a little?

> To get thread safety now, I can synchronize access to the JNI lib
> in Java to enforce single-threadness, but of course it means if I have
> multiple computations wanting to use GLPK, which I do, they have to
> queue for it and I have a central bottleneck.

> 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 rather than the
> entire duration.

You may make glpk code reenterable by replacing the routines
tls_set_ptr and tls_get_ptr in file glpenv02.c (v4.43) with a
appropriate reentrant version. The variable tls (declared as static
in the original non-reentrant version) is a pointer to the glpk
environment. In the reentrant version it must be allocated in the
thread local storage, i.e. each thread should have its own instance
of that variable. This feature is not implemented in glpk due to
portability issues. Please note that reenterability does not mean
thread-safety, i.e. you can call glpk api routines from different
threads, however, each problem object (glp_prob) can be used only in
that thread where it was created.


Andrew Makhorin



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

RE: [Help-glpk] Thread safety of GLPK

[Hammond, Paul]

Yes, I was referred to separate C++ threading libraries that give you threading 
support in C++.

Paul

-Original Message-
From: Michael Hennebry [mailto:henne...@web.cs.ndsu.nodak.edu] 
Sent: 14 April 2010 14:51
To: Hammond, Paul (IDEAS)
Cc: help-glpk@gnu.org; Andrew Makhorin
Subject: RE: [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 it without a huge 
> rewrite?

C++ doesn't know about threads either.
Perhaps you are thinking of some C++-only thread implementation?

-- 
Michael   henne...@web.cs.ndsu.nodak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."

--
NOTICE: If received in error, please destroy, and notify sender. Sender does 
not intend to waive confidentiality or privilege. Use of this email is 
prohibited when received in error. We may monitor and store emails to the 
extent permitted by applicable law.





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

RE: [Help-glpk] Thread safety of GLPK

[Michael Hennebry]

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 know about threads either.
Perhaps you are thinking of some C++-only thread implementation?

--
Michael   henne...@web.cs.ndsu.nodak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."


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

RE: [Help-glpk] Thread safety of GLPK

[Hammond, Paul]

Andrew.

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 source at all or how it works 
internally, so please bear my comments in that light, but in terms of locking, 
if the data structures being used for each computation are completely separate 
copies in each thread, I'm not sure where the demand for locking arises, 
perhaps you could elaborate a little?

To get thread safety now, I can synchronize access to the JNI lib in Java to 
enforce single-threadness, but of course it means if I have multiple 
computations wanting to use GLPK, which I do, they have to queue for it and I 
have a central bottleneck.

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 rather than the entire duration.

Thx.

Paul

-Original 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, 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.

Thread safety (unlike re-enterability) requires locking/unlocking
program objects used by concurrent threads. Since the standard C does
not provide such a feature, there are no plans in this direction.

I'm just wondering how you would use glpk if it were thread safe?
Thanks.


Andrew Makhorin


--
NOTICE: If received in error, please destroy, and notify sender. Sender does 
not intend to waive confidentiality or privilege. Use of this email is 
prohibited when received in error. We may monitor and store emails to the 
extent permitted by applicable law.





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

Re: [Help-glpk] Thread safety of GLPK

[Andrew Makhorin]

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

Thread safety (unlike re-enterability) requires locking/unlocking
program objects used by concurrent threads. Since the standard C does
not provide such a feature, there are no plans in this direction.

I'm just wondering how you would use glpk if it were thread safe?
Thanks.


Andrew Makhorin



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

Re: [Help-glpk] Thread safety of GLPK

[glpk xypron]

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/2005-04/msg00027.html
http://lists.gnu.org/archive/html/help-glpk/2007-08/msg00040.html
http://lists.gnu.org/archive/html/help-glpk/2009-03/msg00049.html
http://lists.gnu.org/archive/html/help-glpk/2009-07/msg0.html

Please, read the thread starting at
http://lists.gnu.org/archive/html/help-glpk/2009-07/msg0.html

It indicates some of the areas that make GLPK not threadsafe.

Best regards

Xypron
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


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

Re: [Help-glpk] Thread safety of GLPK

[Michael Hennebry]

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


GLPK is not thread-safe.
What you might do is dedicate a thread to GLPK.
Communicate through messages.

--
Michael   henne...@web.cs.ndsu.nodak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."


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

[Help-glpk] Thread safety of GLPK

[Hammond, Paul]

Hi,

 

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

 

Thx.

 

Paul

 









NOTICE: If received in error, please destroy, and notify sender. Sender does 
not intend to waive confidentiality or privilege. Use of this email is 
prohibited when received in error. We may monitor and store emails to the 
extent permitted by applicable law.





 




Hi,

 

I’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 GLPK.

 

Thx.

 

Paul

 







NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.

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