Re: ReaderWriterLockSlim + Dispose?

I only thought you said that because you did. I'm happy if you want to
retract the previous example, but you did post that scenario as an example.

That was an example to illustrate what would happen if you got past
the (disposable) lock before it disposed, but not result in a crash
and be a valid "not care about the results anymore"; user wise. If it
was before the lock when it disposed, then it wouldn't result in any
output because it'd see the object is disposed and just skip to the
end. It's like using it to generlize the topic to chat programs only
- "whats all this talk about thread pools, I thought we were talking
about chat programs"

Again: I never once suggested that you _should_ be aborting thread pool

Amusing, red herring? You gave the example. Said its the only valid
way if you were in that situation to safly clean up (which I
dissagreeded with). You can keep following the straw man argument
above if you like, but don't tell me to not try to refret the "only"
way to safly dispose the thread pool without waiting argument you
gave, and then call it a red herring.

However, Microsoft does also specifically _recommend_ that
if you implement Dispose() that it be valid to call Dispose() multiple
times safely.

I didn't design the dispose pattern. It comes with a "disposed" flag
that they expect you to use. What if 2 objects try to dispose at the
same time, and both objects try setting the "disposed" flag to false
at the same time? Is the design patter flawed? Not really, the
situation doesn't really occur ever, but it probably can since who
knows when the GC will call it. I wouldn't spend too much time trying
to fix this situation even though it can potentially exsist.

"Most likely never happen" is NEVER an appropriate design
philosophy.

I'm not too sure about this statment... It's not that perfect of a
world.

It's no more off-topic than any other programming design thread

:) It's definally off-topic, but I retract my previous statment. It's
not pathedic, I don't know why I said that. I don't see myself as the
kind of person who has a problem admiting I made a mistake, I just
don't agree with your view.

In my opinion, it's possible to (as reliably as other programs), clean
up an object and not be forced to wait for the threads inside it to
finish, or force threads to stop with an abort. Mainly in the case
where you don't care about the result of the threads anymore. Another
example could be that you send 100 threads off to get an answer, you
got the answer when the 3rd thread returned. You can do clean up and
ignore the other threads as long as you have dispose checks (or try
catch statments (or both)), around the objects you clean up.

Now don't get me wrong. A disposable sychronization lock did seem
very strange to me (point of the topic), and obviously makes using
this type of lock in a situation where you want to do fast clean up
makes it harder (if statmtnet, or try catch statments, everytime you
try and aquire a lock). But this isn't a bad design, the benifites
can be good.


IE in the previous example changing all the "if(!disposed)
myStringLock.EnterWriteLock(); else return;" to "try
{ myStringLock.EnterWriteLock(); } catch { return; }" would fix any
possible crashes, and be a concret example with no possible chance of
crashing, yet have everything synched.

:) NB
.

Relevant Pages

  • Re: Oldest item in your freezer??? (Gagger warning)
    ... my brother was helping her clean out her basement and he came across a freezer that had gotten unplugged years back, and my grandmother never bothered to clean it out. ... It was full of evil goo, and when he called the city to find out how to dispose of it, they suggested he wear a hazmat suit of sorts, and not to open it ndoors again. ... The basement is also home to six inches or so of compacted stuff that is near-permanently affixed to the floor from numerous floods. ... She takes a water exercise class at the local JCC, and takes home leftovers from ...
    (rec.food.cooking)
  • Re: ReaderWriterLockSlim + Dispose?
    ... As a result it'll clean up as intended even if it wasn't ... Yes all "fast clean" dispose objects need to ... it'll either put more effort into your design ... A couple try/catch statment with some simple clean up in the catch ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: garbage prophecy
    ... therefore, of the entire universe, of which we must be but an ... could help by keeping it clean. ... because the fees to dispose of these items were causing people to find ... we just have to make sure the locals know they can dispose of this ...
    (alt.gathering.rainbow)
  • Re: ReaderWriterLockSlim + Dispose?
    ... The thread won't "clean up as intended". ... Yes all "fast clean" dispose objects need to ... It does if you want to maintain it as a workable design philosophy (and even then, it's still higher maintenance than the correct way to do it). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Dispose
    ... i.e. the GC will clean up my objects. ... why should I have to Dispose of a Bitmap? ... understand the internals (pixels are create in C world), ...
    (microsoft.public.dotnet.framework.compactframework)
Loading