C# and garbage collection

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Kyle Kaitan

    C# and garbage collection

    I have got two classes, one is Device and the other is Buffer. Every Buffer
    instance has an associated Device instance, since all Buffers have to be
    created with Device.CreateBu ffer(). Now i want to be able to notify an event
    to all Buffer instances associated with a certain Device. At the same time i
    would like the Buffer instances to be garbage collected, if there is no
    reference from the client code (the one that called Device.CreateBu ffer)
    anymore. The problem is that the Device instance still holds a reference to
    the otherwise unreferenced Buffer, preventing it from being garbage
    collected.

    I could solve the problem with a Destroy() method on the Buffer class, that
    deletes itself from the notify-list of the Device instance. But having this
    explicit destroy instruction is not really nice in a managed environment.

    Someone's told me about WeakReference objects, but they look more like a
    workaround than a solution. Any hints?


  • Nicholas Paldino [.NET/C# MVP]

    #2
    Re: C# and garbage collection

    Kyle,

    Those are really the only two options you have. You wouldn't use a
    Destroy method, but rather, you would implement IDisposable, and call
    Dispose on the Device class. The Dispose method would notify the Device
    that created it to let go.

    The other way (and personally, I think more elegant way) would be to use
    WeakReferences, as they are created for a situation like this. It would
    prevent the need for a Dispose method. When you store the Buffers in the
    Device instance, you would store WeakReferences. You could do general
    cleanup every once in a while, reducing the list of WeakReferences that you
    have, but that's about the only major obstacle.

    Hope this helps.

    --
    - Nicholas Paldino [.NET/C# MVP]
    - mvp@spam.guard. caspershouse.co m

    "Kyle Kaitan" <kkaitan [at] gmail [dot] com> wrote in message
    news:OHw4DUU3EH A.2180@TK2MSFTN GP10.phx.gbl...[color=blue]
    >I have got two classes, one is Device and the other is Buffer. Every Buffer
    > instance has an associated Device instance, since all Buffers have to be
    > created with Device.CreateBu ffer(). Now i want to be able to notify an
    > event
    > to all Buffer instances associated with a certain Device. At the same time
    > i
    > would like the Buffer instances to be garbage collected, if there is no
    > reference from the client code (the one that called Device.CreateBu ffer)
    > anymore. The problem is that the Device instance still holds a reference
    > to
    > the otherwise unreferenced Buffer, preventing it from being garbage
    > collected.
    >
    > I could solve the problem with a Destroy() method on the Buffer class,
    > that
    > deletes itself from the notify-list of the Device instance. But having
    > this
    > explicit destroy instruction is not really nice in a managed environment.
    >
    > Someone's told me about WeakReference objects, but they look more like a
    > workaround than a solution. Any hints?
    >
    >[/color]


    Comment

    • jdmartinez@ea.com

      #3
      Re: C# and garbage collection

      why isn't that nice? there's nothing wrong with explicitly calling
      Destroy() or even Dispose() for that matter ... there's a whole
      language construct dedicated to making sure Dispose() gets called
      (using).

      Joel Martinez
      http://www.onetug.org - Orlando .NET User Group
      http://www.codecube.net - blog

      Comment

      • J.Marsch

        #4
        Re: C# and garbage collection

        I wouldn't say that there is anything wrong with using Dispose(), but I
        would opt for the weak ref. If you rely on Dispose, then you are relying on
        the developer who uses the code to remember to call dispose. If you use the
        weak ref, it will "just work".

        Personally, I'm not a real fan of dispose. The problem is consistency:
        Some objects implement a dispose, and some don't. If you're paying
        attention, good for you, but what about the guys who aren't? The fact that
        it's only there some of the time, means that there is no habit-forming (with
        Delphi, for example, if you created it, you destroyed it -- easy). Further,
        if you have rev 1 of an object and it does not require a dispose, and then
        in a future rev, you add one, now you potentially have a bunch of code to
        track down and add disposes. When you think about it in terms of lifecycle,
        the dispose pattern is really kind of ugly, and it's one of the very few
        things about .Net that doesn't quite sit right with me.

        <jdmartinez@ea. com> wrote in message
        news:1102525692 .277773.234360@ c13g2000cwb.goo glegroups.com.. .[color=blue]
        > why isn't that nice? there's nothing wrong with explicitly calling
        > Destroy() or even Dispose() for that matter ... there's a whole
        > language construct dedicated to making sure Dispose() gets called
        > (using).
        >
        > Joel Martinez
        > http://www.onetug.org - Orlando .NET User Group
        > http://www.codecube.net - blog
        >[/color]


        Comment

        Working...