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

[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

[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 m...@gnu.org 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 `log10Bah, humbug.

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


On Thu, Apr 22, 2010 at 3:30 PM, Andrew Makhorin m...@gnu.org 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

[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

[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

[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

[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 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: 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 pthread.h
 #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 pthread.h
 #include stdio.h
 #include stdlib.h
 #include glpk.h

 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

[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

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

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

[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

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

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

[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

[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

[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