[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] Multi-thread questions
From: |
Reginald Beardsley |
Subject: |
Re: [Help-glpk] Multi-thread questions |
Date: |
Sat, 12 Oct 2013 06:18:39 -0700 (PDT) |
I'm a bit baffled by "serialization and deserialization". What's meant by
that? What is being serialized?
As I understand things the goal is to run a set of independent problems in
parallel and then pick the optimal answer from among the results. That's quite
easy just using glpsol and the standard *nix shell programs which are readily
available on any system including Windows. It's so simple that it's less work
than the discussion about multi-threading alone without doing any programming.
Is there more to it? It seems to me that a clear statement of the problem is
the first step to a solution.
--------------------------------------------
On Sat, 10/12/13, Paolo Bolzoni <address@hidden> wrote:
Subject: Re: [Help-glpk] Multi-thread questions
To:
Cc: "address@hidden" <address@hidden>
Date: Saturday, October 12, 2013, 6:06 AM
On Sat, Oct 12, 2013 at 7:11 AM, Joey
Rios <address@hidden>
wrote:
>> In my scenario, I have many linear problems and I
have to find the one
>> with
>> the maximum solution. Parallelism is easy for this
scenario since there is
>> nothing to share, just find the best.
>
> If there is nothing to share between your problems, you
probably should take
> the advice of Marc and just use scripted calls to
glpsol. Your concern of
> serialization and deserialization does not really
explain why calling glpsol
> this way would be a problem.
To create the problems we just need to loop over few data
structures.
It might be uncommon in general, but to serialize and
deserialize
would be much more code. It is definitely an option, but if
possible we
like the paths of less resistance.
But I am getting the point maybe the best is indeed this
choice and await
that C11 implemented by compilers. (I expect no more
portability problems
after... isnt it?)
> The main thing you should do is replace all of the
calls to glpk's custom
> memory allocation routines with a basic malloc
call. Likewise, replace the
> glpk custom free calls with regular 'free' calls.
There is one more place
> that you have to do something, but I forget where it is
(somewhere in the
> TLS stuff like you mention). The code has changed since
4.44, but here is a
> patch that I used on that version of the code to create
a threaded version
> of the glpk library:
>
> http://sourceforge.net/p/dwsolver/code/ci/master/tree/glpk-4.44.ThreadReady.patch
Thanks!
_______________________________________________
Help-glpk mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/help-glpk