help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] GLPK re-endrant


From: Nigel Galloway
Subject: Re: [Help-glpk] GLPK re-endrant
Date: Thu, 2 Jul 2009 14:24:18 +0100

Code is re-enterant if it may be executed by itself, or by another routine, by 
interupting the present execution.

The 'by itself' bit is usually known as recursion. Code applying a lock and 
then calling itself is usually fatal.

The lock is really used to stop another routine executing a non-renterant piece 
of code while something else is executing it, thus making it thread safe.

It probably isn't suprising that code with a lock is not reenterant, since the 
way to make code renterant is to ensure that all variables modified by the code 
are allocated as instances of the object, which would defeat the purpose of the 
lock which must be static.

> ----- Original Message -----
> From: xypron <address@hidden>
> To: address@hidden
> Subject: Re: [Help-glpk] GLPK re-endrant
> Date: Wed, 1 Jul 2009 12:19:05 -0700 (PDT)
> 
> 
> 
> Hello Joey,
> 
> your patch indicates some of the code regions that are not reentrant.
> 
> (The xmalloc and xfree function offer the possibility to hunt down memory
> leaks and have been quite valuable in development of GLPK.)
> 
> If GLPK would only address POSIX systems the library pthread could be used
> to create the necessary locks to make the code reentrant. An idea is given
> in
> http://www.megacoder.com/files/presentation/Thread-Safe_Programming.pdf
> Thread-Safe Programming
> 
> Including a library like  http://openmp.org/wp/ OpenMP
> would allow creating code that is both threadsafe and easy
> to compile on diverse systems.
> 
> OpenMP is available with GCC, VisualStudio 2008 and other compilers:
> http://openmp.org/wp/openmp-compilers/ OpenMP Compilers
> 
> Best regards
> 
> Xypron
> 
> 
> Rios, Joseph L. (ARC-AFO) wrote:
> >
> > Andrew may want to avert his eyes... it isn't pretty, but it
> > works.  Basically you replace GLPK's memory management with regular
> > malloc()
> > and free() calls within glplib07.c and then you make a couple of hacks in
> > glplib10.c.  I left all of the original lines as comments to better see
> > the
> > changes.  If anyone tries this, please verify that the patch works as
> > advertised as I may have forgotten some other change I made.  Oh, my
> > changes
> > were based on 4.28 I think.
> >
> >
> 
> --
> View this message in context: 
> http://www.nabble.com/GLPK-re-endrant-tp24256046p24295635.html
> Sent from the Gnu - GLPK - Help mailing list archive at Nabble.com.
> 
> 
> 
> _______________________________________________
> Help-glpk mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-glpk

>


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze




reply via email to

[Prev in Thread] Current Thread [Next in Thread]