[gecode-users] Multithreading executions crash

Christian Schulte cschulte at kth.se
Tue Apr 15 16:27:37 CEST 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20140415/0b3285ca/attachment.html>


More information about the users mailing list