Article View: comp.graphics.explorer
Article #87Re: Reference counts
From: Robert Skinner
Date: Mon, 17 Aug 1992 20:25
Date: Mon, 17 Aug 1992 20:25
64 lines
3474 bytes
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!robertReferences:
<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