Re: [Help-glpk] Patch to configure a reentrant version of GLPK

[David Monniaux]

Hi
> I think that running glpk in multiple threads is rather an exception
> needed mainly in interactive programs and in some other exotic
> applications, so in my opinion this option should be disabled by
> default.

I see the matter otherwise.

1) Putting this variable in thread-local storage using _Thread_local or similar 
costs nothing on platforms that supports it [maybe I'm wrong ?].

2) On other platforms, the configure file will simply elect not to put it in 
thread-local storage.

3) Linux etc. packagers generally compile packages with default options, which 
means that if thread-safety is required, users will have to compile their own 
special version of glpk instead of relying on distributed packages. This is 
time-consuming and error-prone (e.g. the program gets linked to one library but 
the dynamic linker uses another one).

4) Running glpk in multiple threads occurs when e.g. one uses OpenMP. More 
generally, all current machines are multicore, and a very natural way to 
exploit that is to run multiple threads. The alternative is to use multiple 
processes, which is fine when one has a number of large problems to solve but 
may be prohibitively costly and/or complicated if one has a large numbers of 
small problems to solve.

Therefore I think --enable-reentrant should be the default, with a graceful 
fallback to disabling it on platforms that support none of the three 
thread-local keywords being tested: it costs nothing and has benefits.

Regards

Monniaux, David.vcf
Description: Text Data