[gecode-users] Multithreading executions crash

[Andrea Peano]

On Wed, Apr 16, 2014 at 2:16 AM, Guido Tack <tack at gecode.org> wrote:

> Hi Andrea,
>
> two things you could try:
> 1) if backup is a global variable, you need to protect it with a mutex,
> since clone is not thread-safe.
> 2) you're using the clones you create in different threads, so you should
> pass "false" to clone instead of "true" (that way the clone is really
> independent of backup and doesn't share any data structures with it)
>

Hi,
it works perfectly!

Thank you,
Andrea


>
> Cheers,
> Guido
>
> On 16 Apr 2014, at 1:07 am, Andrea Peano <andrea.peano at unife.it> wrote:
>
> Thanks for your reply.
>
> I tried to simplify my real architecture, maybe too much!
>
> I create a "backup" space before starting the search, that is a copy of
> the original space used during the search, and it is a global variable of
> the code.
>
> Within the ::post function I create a copy of the backup model, I update
> this space by passing the current (partial) solution, and then I search the
> first sol, like that:
> MyModel *inner_model=static_cast<MyModel *>(backup->clone(true));
> inner_model->update_variables(this->partial_sol_values());
> inner_model->status();
> ...
> inner_dfs.next();
>
> Scary stuff again, I guess!
>
> In general, I need of a partial solution before starting the second step
> in order to run some scary heuristics :)
>
> You refer to this discussion:
> http://www.gecode.org/pipermail/users/2013-January/003769.html
> don't you?
>
> Thanks,
> Andrea
>
>
> On Tue, Apr 15, 2014 at 4:27 PM, Christian Schulte <cschulte at kth.se>wrote:
>
>> Hi Andrea,
>>
>>
>>
>> Whoa! Scary stuff ;-) That's not possible to clone a space that is
>> currently in use for propagation (because that is what is still going on
>> when the ::post function is executed).
>>
>>
>>
>> However it should work much much easier: there has been a discussion in
>> this users group a while ago on how to split search into two parts. Then
>> you can parallelize each one. Just go through the archive (or maybe one of
>> the users who took part in the discussion can help here).
>>
>>
>>
>> Cheers
>>
>> Christian
>>
>>
>>
>> --
>>
>> Christian Schulte, Professor of Computer Science, KTH,
>> www.ict.kth.se/~cschulte/
>>
>>
>>
>> *From:* users-bounces at gecode.org [mailto:users-bounces at gecode.org] *On
>> Behalf Of *Andrea Peano
>> *Sent:* Tuesday, April 15, 2014 2:35 PM
>> *To:* users at gecode.org
>> *Subject:* [gecode-users] Multithreading executions crash
>>
>>
>>
>> Hello everyone,
>>
>> my model is solved by a two-steps search. The first step can be a DFS as
>> well as a BAB search, the second step is always a DFS.
>>
>>
>>
>> I implemented this search by following the section "Executing code
>> between branchers" of the Gecode's guide, like this:
>>
>> branch(*this, MyModel::post)
>>
>>
>>
>> The function "post" copies the current space into a local variable, then
>> instantiates a new DFS engine and finally calls the method "next", in order
>> to compute only the first solution.
>>
>>
>>
>> MyModel *inner_model=static_cast<MyModel *>(this->clone(true));
>>
>> inner_model->status();
>>
>> ...
>>
>> inner_dfs.next();
>>
>>
>>
>> The idea is to parallelize the first level of the search... but if I use
>> only one thread everything works fine, otherwise every time the execution
>> crashes on a different instruction of the function "post".
>>
>>
>>
>> Do you have any clue about this behavior?
>>
>> The worst scenario I see is that this solving architecture is totally
>> incompatible with the multithreading system implemented in Gecode.
>>
>>
>>
>> Thanks,
>>
>> Andrea
>>
>
>
>
> --
>
> Andrea Peano - PhD student
> Department of Engineering - University of Ferrara
> Tel: +39 0532 97 4827
>  _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
>
>
>


-- 

Andrea Peano - PhD student
Department of Engineering - University of Ferrara
Tel: +39 0532 97 4827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20140424/2f06f6fd/attachment.html>