[Fwd: GLPK 4.38 Re-entrancy 64-bit windows]

[Andrew Makhorin]

-------- Forwarded Message --------
From: Nicholas Nash <nicholas.nash@...>
To: help-glpk@...
Subject: GLPK 4.38 Re-entrancy 64-bit windows
Date: Thu, 10 May 2012 20:12:13 +0100



Hi,

 

I have some legacy code that is using GLPK 4.38, despite much searching
online I can’t get definitive answers to some questions.

 

Is GLPK 4.38 re-entrant? The code I have is multi-threaded and running
in a Windows 64-bit environment, calling GLPK from C#.

A single GLPK problem is only ever accessed in a single thread; although
many threads create their own GLPK problems and solve them.

 

I can see code in glplib02.c that allocates thread local storage, so am
I correct that the usage I have described above is safe?

 

Despite using GLPK as above, I still occasionally see this error
reported:

 

xfree: memory allocation error

Error detected in file ..\src\glplib07.c at line 181

 

Since I’m not out of memory, guessing at the code makes it looks like
there was an unmatched free/delete (or there was a threading issue
related to a counter).

 

Is this a known bug in GLPK 4.38, or is the bug more likely to be mine?

Would moving to a later version help?

 

Thanks,

 

Nick



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

[xypron]

Hello Nicholas,

your message had to be forwarded manually because you are not subscribed to the GLPK help list.

No version of GLPK is thread safe. The current version of GLPK is 4.47.

Best regards

Xypron

> -------- Forwarded Message --------
> Subject: GLPK 4.38 Re-entrancy 64-bit windows
> Date: Thu, 10 May 2012 20:12:13 +0100
>
>
>
> Hi,
>
>  
>
> I have some legacy code that is using GLPK 4.38, despite much searching
> online I can’t get definitive answers to some questions.
>
>  
>
> Is GLPK 4.38 re-entrant? The code I have is multi-threaded and running
> in a Windows 64-bit environment, calling GLPK from C#.
>
> A single GLPK problem is only ever accessed in a single thread; although
> many threads create their own GLPK problems and solve them.
>
>  
>
> I can see code in glplib02.c that allocates thread local storage, so am
> I correct that the usage I have described above is safe?
>
>  
>
> Despite using GLPK as above, I still occasionally see this error
> reported:
>
>  
>
> xfree: memory allocation error
>
> Error detected in file ..\src\glplib07.c at line 181
>
>  
>
> Since I’m not out of memory, guessing at the code makes it looks like
> there was an unmatched free/delete (or there was a threading issue
> related to a counter).
>
>  
>
> Is this a known bug in GLPK 4.38, or is the bug more likely to be mine?
>
> Would moving to a later version help?
>
>  
>
> Thanks,
>
>  
>
> Nick
>
>
>
> _______________________________________________
> Help-glpk mailing list
> Help-glpk@...
> https://lists.gnu.org/mailman/listinfo/help-glpk

--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

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