[Help-glpk] Re: re-entrant test version of GLPK

[Andrew Makhorin]

>>> This is IMHO stuff that are nice to have, but nothing that
>>> one could not live without if needed.
>>
>> Right. I do not see where reenterability is needed except the cases
>> when glpk is used in some
>> exotic environments like Java or Python :+)
>>
>I'm a little surprised at these two statements (even accounting for the 
>smiley).  I would have thought that branch-and-bound would have been a 
>great candidate for multi-threaded implementation even outside of Java 
>and Python, so that a multi-processor machine could be utilized most 
>effectively.
>
>An implementation which had one worker thread per processor and put the 
>branch subproblems into a thread would seem to have a major performance 
>advantage on big iron (to me anyway).

Probably I have been misunderstood. Multitasking does not assume
reenterability and vice versa, so even if glpk routines were reentrant
(which they will in the next release), this would not involve
parallelizing the branch-and-bound. Reenterability simply means that
the code does not modify static data like reusability means that the
code does not modify itself. In principle, any code can be easily made
reentrant by using appropriate programming technique, i.e.
reenterability is a property of the code, not of the algorithm.

Andrew Makhorin