[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] Patch to configure a reentrant version of GLPK
From: |
David Monniaux |
Subject: |
Re: [Help-glpk] Patch to configure a reentrant version of GLPK |
Date: |
Mon, 9 Jan 2017 12:52:10 +0100 (CET) |
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