Andrew.
I'm thinking since it is written in C, and C is source compatible with C++,
since C++ does support locking in threads, if one was to treat it as a C++ app
written mostly in C, it may be possible to multi-thread it without a huge
rewrite?
I say this without any knowledge of the GLPK
On Wed, 14 Apr 2010, Hammond, Paul wrote:
I'm thinking since it is written in C, and C is source compatible with C++,
since C++ does support locking in threads, if one was to treat it as a C++ app
written mostly in C, it may be possible to multi-thread it without a huge
rewrite?
C++
Yes, I was referred to separate C++ threading libraries that give you threading
support in C++.
Paul
-Original Message-
From: Michael Hennebry [mailto:henne...@web.cs.ndsu.nodak.edu]
Sent: 14 April 2010 14:51
To: Hammond, Paul (IDEAS)
Cc: help-glpk@gnu.org; Andrew Makhorin
Subject: RE:
Paul,
I'm thinking since it is written in C, and C is source compatible
with C++, since C++ does support locking in threads, if one was to
treat it as a C++ app written mostly in C, it may be possible to
multi-thread it without a huge rewrite?
I say this without any knowledge of the GLPK
On Wed, 14 Apr 2010, Hammond, Paul wrote:
So I guess I just don't mean thread safe, I mean thread hot, as in I can have
multiple GLPK computations going in separate threads simultaneously which don't
need to synchronize on anything or if they do, it's for a very small part of
the computation
...but if you implement locking, then then you will have thread-safety
but not full concurrency (at least in the critical sections). You'd be
better off collecting all the non-sharable state in a structure that
that each thread creates and passes around as an extra function
parameter - i.e.
I wonder if it would be feasible to re-implement this using the
posix threads API
The main routine should call pthread_key_create to create a thread
specific location used to store a pointer to the glpk environment
block. The routine tls_set_ptr should call pthread_setspecific to
store the
