[Osi] osicpx threaded
mjs at clemson.edu
Fri Aug 28 09:02:06 EDT 2009
I'm not sure that thread safety is quite that simple. You may have
eliminated some of the obvious races, but it wouldn't surprise me to
find other hidden ones that don't crop up as frequently. OSI really
needs a more comprehensive audit for thread safety, which we are aware
of and which is on my agenda.
If you have patches that you think make a good starting point, I'm glad
to have them. The best place to keep them is probably attached to a
On Fri, 2009-08-28 at 01:57 -0400, Matthew Galati wrote:
> FYI. If I remove all the references to static env_, version, etc...
> things seem to work fine now. OsiCpx is then thread-safe.
> Can this be changed? or at least provided as an option? It is a shame
> if one cannot use Osi in a multi-threaded environment.
> From: osi-bounces at list.coin-or.org [osi-bounces at list.coin-or.org] On
> Behalf Of Matthew Galati [magh at lehigh.edu]
> Sent: Thursday, August 27, 2009 11:55 PM
> To: osi at list.coin-or.org
> Subject: [Osi] osicpx threaded
> Has anyone successfully used more than one instance/thread of OsiCpx
> simultaneously? I am trying to do this. Constructing 2 instances of
> OsiCpx and using standard pthreads, solve two MILPs on 2 threads. It
> crashes. Valgrind/Helgrind is showing lots of potential race
> conditions. Looking a little deeper into OsiCpx, I noticed that
> although I have two different CpxLp ptrs, I have one CpxEnv ptr. In
> fact, the cpx env is a static variable in OsiCpx. Doesn't this make
> OsiCpx not thread-safe? Is there any easy way around this?
> Osi mailing list
> Osi at list.coin-or.org
Clemson University Math Sciences
mjs AT clemson DOT edu
More information about the Osi