Should the Dispose( ) method only run when there are no other references to an object?

[Steve Richter]

I understand the IDisposable interface and how the using instruction
will call the Dispose method of an object.

What if a reference to an object is passed to a 2nd thread? And the
object contains a handle to an open file. The Dispose( ) method closes
the handle.

How would the Dispose( ) method called from the end of the using block
in the 1st thread know that references to the object still exists in
other threads?

thanks,

-Steve

[Brian Gideon]

Steve,

It wouldn't. But, as the programmer you would know about other
references and code accordingly for those situations. In other words,
if you allow an object to be used in other threads don't dispose it
until those threads are done with it.

Brian

Steve Richter wrote:

I understand the IDisposable interface and how the using instruction
will call the Dispose method of an object.

What if a reference to an object is passed to a 2nd thread? And the
object contains a handle to an open file. The Dispose( ) method closes
the handle.

How would the Dispose( ) method called from the end of the using block
in the 1st thread know that references to the object still exists in
other threads?

thanks,

-Steve

[Steve Richter]

Brian Gideon wrote:

Steve,

It wouldn't. But, as the programmer you would know about other
references and code accordingly for those situations. In other words,
if you allow an object to be used in other threads don't dispose it
until those threads are done with it.

thanks for confirming that. I can accept that I have to program for it.
I am thinking that the absence of reference counting from .NET objects
is a failing of its design. Can I define a ReferenceCountO bject class
that is derived from Object. Then base any class of mine that I want to
maintain a reference count in from that class? How would such a class
work to update the reference count when the object is passed by
reference to a method or added to a list?

-Steve

>
Steve Richter wrote:

I understand the IDisposable interface and how the using instruction
will call the Dispose method of an object.

What if a reference to an object is passed to a 2nd thread? And the
object contains a handle to an open file. The Dispose( ) method closes
the handle.

How would the Dispose( ) method called from the end of the using block
in the 1st thread know that references to the object still exists in
other threads?

thanks,

-Steve

[Michael C]

"Steve Richter" <St************ @gmail.comwrote in message
news:11******** **************@ s34g2000cwa.goo glegroups.com.. .

thanks for confirming that. I can accept that I have to program for it.
I am thinking that the absence of reference counting from .NET objects
is a failing of its design.

It's not a failing, the very idea was to get rid of ref counting.

Can I define a ReferenceCountO bject class
that is derived from Object. Then base any class of mine that I want to
maintain a reference count in from that class? How would such a class
work to update the reference count when the object is passed by
reference to a method or added to a list?

This is one way you could do it. There would be plenty of other custom
methods you could use also which would all be just that, custom. Generally I
would have thought you'd have 1 thread being the owner of the object and
that thread handles to lifetime of that object. If it's passed the object to
another thread then it would know and not dispose it.

Michael

[David Browne]

"Michael C" <no****@nospam. comwrote in message
news:eS******** ******@TK2MSFTN GP05.phx.gbl...

"Steve Richter" <St************ @gmail.comwrote in message
news:11******** **************@ s34g2000cwa.goo glegroups.com.. .

>thanks for confirming that. I can accept that I have to program for it.
I am thinking that the absence of reference counting from .NET objects
is a failing of its design.

It's not a failing, the very idea was to get rid of ref counting.

To be fair, ref counting is semantically superior, but it's more expensive
than garbage collecting.

>

>Can I define a ReferenceCountO bject class
that is derived from Object. Then base any class of mine that I want to
maintain a reference count in from that class? How would such a class
work to update the reference count when the object is passed by
reference to a method or added to a list?

It wouldn't. Reference counting would need to be baked into the low-level
memory management of .NET so that all those reference assignments operations
correctly maintained the reference count.
David

[Steve Richter]

Michael C wrote:

"Steve Richter" <St************ @gmail.comwrote in message
news:11******** **************@ s34g2000cwa.goo glegroups.com.. .

thanks for confirming that. I can accept that I have to program for it.
I am thinking that the absence of reference counting from .NET objects
is a failing of its design.

It's not a failing, the very idea was to get rid of ref counting.

that idea dates back in the way back year of 2000 when the CPU was slow
and the world thought it was at peace. Now with quad cores there are
plenty of cycles to support reference counting. Built in reference
counting makes programming easier - understanding the nuances of
finalization and disposing is not easy.

what I would like is to have an IReference interface with a method that
is called everytime a reference to an object is created. Then another
method is called when the reference goes out of scope.

>

Can I define a ReferenceCountO bject class
that is derived from Object. Then base any class of mine that I want to
maintain a reference count in from that class? How would such a class
work to update the reference count when the object is passed by
reference to a method or added to a list?

This is one way you could do it. There would be plenty of other custom
methods you could use also which would all be just that, custom. Generally I
would have thought you'd have 1 thread being the owner of the object and
that thread handles to lifetime of that object. If it's passed the object to
another thread then it would know and not dispose it.

what if the object is added to a list within the using block? Then at
the end of the block dispose( ) is called and that method has no idea
that references to the object are still alive in an array somewhere.

-Steve

[Cor Ligthert [MVP]]

Steve,

I never understand why people take program languages like C#, which does a
lot for them including finalizing, while they want in fact the features of
Intel assembler.

http://www.intel.com/design/network/...k_download.htm

Cor

"Steve Richter" <St************ @gmail.comschre ef in bericht
news:11******** **************@ s34g2000cwa.goo glegroups.com.. .

>I understand the IDisposable interface and how the using instruction
will call the Dispose method of an object.

What if a reference to an object is passed to a 2nd thread? And the
object contains a handle to an open file. The Dispose( ) method closes
the handle.

How would the Dispose( ) method called from the end of the using block
in the 1st thread know that references to the object still exists in
other threads?

thanks,

-Steve

[Michael C]

"Steve Richter" <St************ @gmail.comwrote in message
news:11******** **************@ v45g2000cwv.goo glegroups.com.. .

that idea dates back in the way back year of 2000 when the CPU was slow
and the world thought it was at peace.

No matter how fast a processor gets an app will still run faster without ref
counting. In some cases quite significantly.

Now with quad cores there are
plenty of cycles to support reference counting.

Dual core CPUs are actually more suited to the .net model because the GC
runs in another thread.

Built in reference
counting makes programming easier - understanding the nuances of
finalization and disposing is not easy.

I don't think it's that much of an issue. When you no longer need an object
and it has a dispose method then call it. I find it *significantly* easier
than dealing with circular reference issues.

what I would like is to have an IReference interface with a method that
is called everytime a reference to an object is created. Then another
method is called when the reference goes out of scope.

AFAIK this is not possible.

what if the object is added to a list within the using block? Then at
the end of the block dispose( ) is called and that method has no idea
that references to the object are still alive in an array somewhere.

This is an issue for you to deal with. This was the same with ref counting
in a lot of cases anyway, eg an ADO recordset having a close method.

Michael

[Christof Nordiek]

Hi Steve,

I think, you have to !design! some rule for the lifetime for all your
disposable objects; then you have to implement it by code.

One simple way to do it, is to use it only locally inside the method were
the disposable is created. This can easily be implemented by a using
statement.
A second way is, to put it in an instance field of a disposable class and
then dispose it in the dispose method of that class. This surely would only
delegate the necessaty of a lifetime rule to the referrer of that outer
class.

There are situations, when the lifetime rule has to be much more
complicated/sofisticated, but still it should be clearly designed first, and
than be implemented.

"Steve Richter" <St************ @gmail.comschri eb im Newsbeitrag
news:11******** **************@ s34g2000cwa.goo glegroups.com.. .

>I understand the IDisposable interface and how the using instruction
will call the Dispose method of an object.

What if a reference to an object is passed to a 2nd thread? And the
object contains a handle to an open file. The Dispose( ) method closes
the handle.

How would the Dispose( ) method called from the end of the using block
in the 1st thread know that references to the object still exists in
other threads?

thanks,

-Steve

[Brian Gideon]

Michael C wrote:

Dual core CPUs are actually more suited to the .net model because the GC
runs in another thread.

Unfortunately, the GC will suspend all application threads so that it
can perform it's work correctly. Now, depending on what version of the
CLR is installed the GC may have one thread running on each processor
or just one thread period. Regardless, the other application threads
are still suspended during the collection process. I suspect in the
future Microsoft will try to take better advantage of the multiple core
processors. Nevertheless, GC is still faster than reference counting
and there's at least a portion of it that can take advantage of
symmetric multiprocessing .