🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.graphics.explorer
Article #87

Re: Reference counts

#87
From: Robert Skinner
Date: Mon, 17 Aug 1992 20:25
64 lines
3474 bytes
In article <1992Jul29.033720.28549@qdpii.comp.qdpi.oz.au>, dres@qdpii.comp.qdpi.oz.au (Drought Research Account) writes:
|> 
|> The question is, if I am reading many files using this, i.e. the module
|> is firing over and over again, I am coninually creating lattices and
|> never free-ing them. Even if all downstream modules manage to decrement
|> their reference counts correctly, on receipt of the next lattice, there does
|> not seem to be any way thet my module can decrement the reference count to the
|> previously created lattice, before creating a new one. What does actually
|> happen is that I slowly fill up more and more of the shared memory
|> arena.
|> 
|> What am I supposed to be doing in this situation ? Any hints ?
|> 

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
Technical Details
Message-ID: <1992Aug17.202556.26846@odin.corp.sgi.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!sgigate!odin!texas.asd.sgi.com!robert
References: <1992Jul29.033720.28549@qdpii.comp.qdpi.oz.au>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!sgigate!odin!texas.asd.sgi.com!robert
From: robert@texas.asd.sgi.com (Robert Skinner)
Newsgroups: comp.graphics.explorer
Subject: Re: Reference counts
Message-ID: <1992Aug17.202556.26846@odin.corp.sgi.com>
Date: 17 Aug 92 20:25:56 GMT
References: <1992Jul29.033720.28549@qdpii.comp.qdpi.oz.au>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: robert@sgi.com
Organization: Silicon Graphics Inc., Advanced Systems Division
Lines: 64
Nntp-Posting-Host: texas.asd.sgi.com