[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Help-glpk] GLPK re-endrant
From: |
Giampaolo Tomassoni |
Subject: |
RE: [Help-glpk] GLPK re-endrant |
Date: |
Thu, 2 Jul 2009 18:08:47 +0200 |
> -----Original Message-----
> From: address@hidden [mailto:help-
> address@hidden On Behalf Of Michael
> Hennebry
> Sent: Thursday, July 02, 2009 5:17 PM
> To: Nigel Galloway
> Cc: address@hidden
> Subject: Re: [Help-glpk] GLPK re-endrant
>
> The reentrancy issue could be obviated by
> running GLPK instances in separate processes.
Nevertheless, most of the software around nowadays is meant to be run by
multi-cored CPUs. So, reentrancy actually seems to me something very close
to a requisite. The GLPK team will surely have to face it ASAP.
Also, I think that a reentrant version of GLPK would not suffer too much
decrease in performances, not even to mention the fact that GLPK could
eventually gain some benefits by exploring further the multithreading area.
What about a multithreaded branch-and-bound algorithm, in example?
OS and framework dependencies would be less than an issue even there, since
the current GLPK approach of the xmalloc/xfree wrappers could be extended to
thread and mutex management.
Giampaolo
> --
> Michael address@hidden
> "Pessimist: The glass is half empty.
> Optimist: The glass is half full.
> Engineer: The glass is twice as big as it needs to be."
- Re: [Help-glpk] GLPK re-endrant, Antonello Lobianco, 2009/07/01
- Re: [Help-glpk] GLPK re-endrant, Nigel Galloway, 2009/07/02
- Re: [Help-glpk] GLPK re-endrant, Michael Hennebry, 2009/07/02
- Re: [Help-glpk] GLPK re-endrant, Rios, Joseph L. (ARC-AFO), 2009/07/02
- RE: [Help-glpk] GLPK re-endrant, D'Agostino, Larry - TX, 2009/07/02
- Re: [Help-glpk] GLPK re-endrant, Rios, Joseph L. (ARC-AFO), 2009/07/02
RE: [Help-glpk] GLPK re-endrant, Giampaolo Tomassoni, 2009/07/02
Re: [Help-glpk] GLPK re-endrant, Andrew Makhorin, 2009/07/03