Thread View: comp.graphics.explorer
2 messages
2 total messages
Started by Drought Research Account
Wed, 29 Jul 1992 03:37
Reference counts
Author: Drought Research Account
Date: Wed, 29 Jul 1992 03:37
Date: Wed, 29 Jul 1992 03:37
19 lines
1259 bytes
1259 bytes
I have written a module which creates a lattice, using cxLatNew. The module is actually to read in an obscure data format, so it needs to read the file first to know how big to create the lattice. This is why I can't just let the module data wrapper create the lattice for me. 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 ? thanks in advance Neil Flood
Re: Reference counts
Author: 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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads