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)
Cheers, Guido On 16 Apr 2014, at 1:07 am, Andrea Peano <andrea.pe...@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 <cschu...@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-boun...@gecode.org [mailto:users-boun...@gecode.org] On Behalf Of > Andrea Peano > Sent: Tuesday, April 15, 2014 2:35 PM > To: users@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@gecode.org > https://www.gecode.org/mailman/listinfo/gecode-users
_______________________________________________ Gecode users mailing list users@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
