🚀 go-pugleaf

In article <13179.2a782989@ohstpy.mps.ohio-state.edu>, pecquet@ohstpy.mps.ohio-state.edu writes:
|> Hello,
|>      I have been having difficulties with modules that I have written 
|> crashing with "exhausted shared memory" errors.  This can be as simple as 
|> two ReadLat's connected as inputs to a module that:
|>      creates internally a new lattice to duplicate (in shape/size) one   
|>        of the input lattices
|>      create a lattice four times larger than the other input lattice (it is
|>        a "4 vector" of the "1 vector" input lattice
|>      using the two input lattices values are copied into the "4 vector"
|>        output lattice
|>      the internal lattice (1st step above) is dereferenced:  i.e.:
|>        cxDataRefDec(lat);
|>      nothing else is going on as far as data allocation/deallocation is
|>        concerned
|> 
|>      With two lattices of about 1.5MB (and having a .explorerrc file in my 
|> home directory containing: arenasize 40mb) the above works several times, 
|> then (at a random execution) dies with the shared memory exhausted error.
|> 
|>      A related question: some of my modules need global data.  I create 
|> lattices and then use cxDataRefInc(lat) on them.  When I need to resize 
|> them, I call cxDataRefDec(lat) and lat = cxLatNew(...).  Does this cause 
|> the unwanted lattices to be discarded and reclaimed by explorer???
|>     Any help would be greatly appreciated...

OK, I'm not sure exactly what you are doing, but the fact that you are
doing cxDataRefInc's and cxDataRefDec's is setting off alarms in my
head.  I would guess that you are decrementing a reference count too
many times, and the data is getting deleted.  Then some other part of
the system tries to use that data and ends up trashing the shared
memory allocation arena.  That is the only reason I know of that
modules should *crash* with "exhausted shared memory" errors.

Included below is a response that I just posted regarding reference
counts.  Read over it, and see if I'm correct about your handling of
the reference counts.  As I say below, unless you are doing something
advanced (and it doesn't sound like it), you don't need to modify the
ref counts at all.  If you still think your code is OK, please send me
a code fragment including all your cxLatNew and cxDataRef{Inc,Dec}
operations.



> You shouldn't have to do anything.  Here's what happens.
> 
> You create a lattice with cxLatNew, it gets a reference count (RC) of 0.
> You put that lattice in an output port (or the module builder does) 
> with cxOutputDataSet(), the output port increments the RC to 1.  
> (So the output port can keep the reference, if you connect a new
> input to it later.)  
> 
> When the module function returns, the output port sends the data to
> each input port its connected to.  The input ports each increment the
> RC (so the data can stay there after the output is disconneted).  The
> final RC of the data will be N+1, where N is the # of inputs its
> connected to.
> 
> Now your module fires again.  You create a new lattice (I'll explain
> why you HAVE to create new lattice below) and it gets put in the
> output port.  The output port increments the RC of the new data to 1,
> and decrements the RC of the old data (here it goes to N).  When each
> of the N input ports get the new data, they increment its RC, and
> decrement the old data.  So the new data will get a count of N+1, as
> before, and the old data's RC will eventually go to 0.  The Input port
> that actually decrements the count to 0 is responsible for reclaiming
> the memory.  
> 
> So basically, if you don't have to do anything advanced, you don't
> have to do anything.  Just leave the RC alone, and the system will
> take care of it.
> 
> Now as to why you HAVE to create a new lattice:  (please skip the rest
> of this article if this is old hat to you, I just got the impression
> somewhere that this was outstanding question here).  Your module has
> no information about whether the downstream modules have finished
> reading your lattice.  If you muck with same lattice (remember, its
> shared memory) while they are executing, they will get inconsistent,
> and sometimes disastrous results.


-- 

Robert Skinner
robert@sgi.com

	My father was no great winner.  He was an alcoholic and a
	gambler.  But he was also very vain, so one time he gave up his
	vices for several months to pay for a hair transplant.  Then, a
	couple of days after the transplant, he shaved his head on a
	$20 bet.
 
	... so I owe him 20 bucks ...		
					unknown comic