I did it too, with no real effect (the memory used by the process grows by 1MB/s, and for job-shop 8 machines x 8 tasks there are 8 edge-finder propagators, each with SharedArray<Int> of size 8). I did not use home.notice(*this,AP_DISPOSE) in copy constructor - it caused crash of the process - but it is neither used in copy constructors in Gecode.
Jan Christian Schulte napsal(a): > For a SharedArray, you have to manually call its destructor in the dispose > method and you have to use notice/ignore as described before. > > For an example, see gecode/element/int.hpp > > Christian > > -- > Christian Schulte, www.ict.kth.se/~cschulte/ > > > -----Original Message----- > From: Jan Kelbel [mailto:kelb...@fel.cvut.cz] > Sent: Monday, May 25, 2009 5:08 PM > To: Christian Schulte > Cc: us...@gecode.org > Subject: Re: [gecode-users] Propagator > > Hi Christian, > > thank you for the answer. From the things you described (and I already > tried, though I not really knew what it is doing), it must be something > else. The propagator has one array created in propagate() method using > Region allocator, that should be freed automatically when the > propagate() returns, and one SharedArray that is shared among all the > copies of one propagator. > > Regards, Jan > > > Christian Schulte napsal(a): >> Hi Jan, >> >> there are the following catches: >> >> a) propagators do not use destructors. Instead, when a propagator is >> deleted, the dispose function is called. That in particular implies that > for >> any member of your propagator you have to explicitly call the member's >> destructor (that is something that is done automatically inside a > destructor >> but not in the dispose function). >> >> b) most likely you are under the assumption that when a space containing >> your propagator is deleted, the dispose method of the propagator is called >> such that memory possibly allocated by your propagator is freed. That is > not >> the case. In case your propagator requires the dispose method to be called >> when a space is deleted, the propagator must register itself with its > space >> for deletion. For example, when home refers to the space, you have to >> register the propagator by >> home.notice(*this, AP_DISPOSE); >> and consequently in the dispose function you have to deregister >> home.ignore(*this, AP_DISPOSE); >> >> The only exception is if your propagator has only allocated memory from > the >> space but not via malloc or something else. Then it does not be deleted > when >> its space is deleted. >> >> Then, the behaviour you describe must have to do with something else as >> there is really nothing special happening for NaryPropagator. Maybe you >> could check your code again. >> >> I think you are referring to the Gecode 2.* implementation of the >> cumulatives propagator. That was actually nonsensical and has been changed >> in 3.*. If no variables are modified by a propagator and the propagator > says >> ES_NOFIX, Gecode still knows that nothing has changed. So finding out >> whether something has changed, and if yes reporting ES_NOFIX and ES_FIX >> otherwise is exactly the same than reporting ES_NOFIX. >> >> I hope that helps >> Christian >> >> -- >> Christian Schulte, www.ict.kth.se/~cschulte/ >> >> >> -----Original Message----- >> From: users-boun...@gecode.org [mailto:users-boun...@gecode.org] On Behalf >> Of Jan Kelbel >> Sent: Monday, May 25, 2009 3:16 PM >> To: us...@gecode.org >> Subject: [gecode-users] Propagator >> >> Hello, >> >> some months ago I implemented N-ary propagator (it is that edge-finder). >> When I used it to solve larger problem instances, I noticed that it >> consumes memory in rate of about 1MB/s. >> I tested it in Gecode 2.2.0 (where it was even about 3MB/s) and in >> Gecode 3.1.0., using MS Visual C++ 2008. >> >> This propagator is inherited from class NaryPropagator. In the propagate >> method, there is an array for sorting, which is created using the Region >> allocation. >> >> When I changed the edge-finder to inherit directly from the class >> Propagator, the growing memory consumption disappeared. >> >> My question is, are there some rules, what should be implemented in >> propagator inherited from NaryPropagator in order allocate/dealocate >> memory correctly? >> >> >> My second question (set of questions) is related to Val propagator for >> cumulatives constrait, which is my study material for implementation of >> scheduling constraints. >> 1) in Val::propagate() file cumulatives/val.hpp >> at line 276 there is a test if all the variables are assigned. Is there >> a reason why in case of subsumed = true; the function ES_SUBSUMED() is >> called as late as at line 386? >> >> 2) Why there is no ES_FIX return from the Val::propagate() method? >> In the documentation is that when the propagator computes fixpoint, it >> should return ES_FIX. >> Is the reason that checking whether fixpoint is reached is expensive, >> and the propagation scheduler arranges that the propagation is not >> executed too many times? >> >> Thank you. >> >> Regards, Jan >> >> >> >> >> _______________________________________________ >> Gecode users mailing list >> us...@gecode.org >> https://www.gecode.org/mailman/listinfo/gecode-users >> > > _______________________________________________ Gecode users mailing list us...@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
