ReaderWriterLockSlim must be Disposed()? What a Pain!

[Jules Winfield]

Friend,

I have a class that contains some data. The data will be accessed from
multiple threads of which 90% are reading and 10% are writing. A private
ReaderWriterLoc kSlim object is used within the class to facilitate
synchronization .

You're probably aware that ReaderWriterLoc kSlim implements IDisposable. So
to honor the contract with ReaderWriteLock Slim, it stands to reason that
*my* class must implement IDisposable so that when my class is disposed, so
is the private lock object.

Here's the problem. Various instances of my class are passed around from
place to place throughout the application and it's impossible for me as the
programmer to determine at precisely what point any given instance of the
class will no longer be referenced. I normally wouldn't care (that's what
the Garbage Collector is for) but in this case, I need to know so that
Dispose() can be called on my class.

The best solution I could come up with is to have my class maintain an
internal reference count. Each time the class is passed to some using
entity, AddRef() is called to increment the count and when that using entity
is done referencing my class, Release() is called to decrement the count.
When the count reaches zero, my class finally calls Dispose() on its
internal lock.

This seems ugly to me. There must be a better way. I know I could just skip
calling Dispose() on the lock and wait for it to be finalized, but who knows
when that'll happen? Maybe never.

Is there some kind of design pattern that's used in such cases?

Thanks.

[Peter Duniho]

Re: ReaderWriterLoc kSlim must be Disposed()? What a Pain!

On Mon, 25 Aug 2008 16:26:25 -0700, Jules Winfield
<Jules.Winfield @newsgroup.nosp amwrote:

[...]
You're probably aware that ReaderWriterLoc kSlim implements IDisposable.
So
to honor the contract with ReaderWriteLock Slim, it stands to reason that
*my* class must implement IDisposable so that when my class is disposed,
so
is the private lock object.
>
[...]
The best solution I could come up with is to have my class maintain an
internal reference count. Each time the class is passed to some using
entity, AddRef() is called to increment the count and when that using
entity
is done referencing my class, Release() is called to decrement the count.
When the count reaches zero, my class finally calls Dispose() on its
internal lock.
>
This seems ugly to me. There must be a better way. I know I could just
skip
calling Dispose() on the lock and wait for it to be finalized, but who
knows
when that'll happen? Maybe never.
>
Is there some kind of design pattern that's used in such cases?

Ref-counting is a reasonably tried-and-true design. Granted, I prefer not
to use it in C#/.NET programming, because it's a bit contrary to the whole
garbage-collecting paradigm. But there's not really anything
fundamentally wrong with it (other than it being error-prone :) ).

IMHO, the preferable solution is to create the design so that there's
clear ownership of an object, in a single place of code. That is, if
you've got code that's implementing multiple clients of this shared,
disposable object, then that code shouldn't care at all about disposing
it. There should be some single-point code that manages the object, and
which itself is already aware of the status of the clients.

For example, if you've got multiple readers, there presumably there's some
other code that knows how many readers there are, what their lifetime is,
etc. That other code is where ownership of the shared, disposable object
should be IMHO.

But if for some reason that doesn't work for you, ref-counting seems
reasonable to me. I think I'd prefer that solution to that of using the
disposal of the object as a signal for the clients to stop using it (by
catching the ObjectDisposedE xception). :)

Pete