Re: ReaderWriterLockSlim + Dispose?

On Apr 5, 8:00 pm, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
On Sat, 05 Apr 2008 16:01:50 -0700, NvrBst <nvr...@xxxxxxxxx> wrote:
I was talking about the Managed ThreadPool, not a custom made one;

So was I.

the
one you usally access with "ThreadPool.QueueUserWorkItem(...)".  After
you start a thread on the threadpool then you can't stop it without a
volatile flag.

You can call Thread.Abort() on one of those threads as easily as on any  
other thread, provided you have a reference to the thread.  You can always  
get a reference to the thread by getting Thread.CurrentThread inside the  
worker thread.

Maybe you could have the work items list themselves
someplace static so you could call abort from another thread, but I'm
not sure if its possible.

Yes, it's possible.  And it's exactly what you'd have to do, should you  
decide to use Thread.Abort() to interrupt the thread.

Personally, I feel that using Thread.Abort() is a bad idea, and it's not  
what I was suggesting you might do.  But it certainly is possible.

 What benefit is there in doing some of the cleanup early, and
then still waiting on the threads?  Especially when that cleanup removes
objects that the threads need to use?

I can only list situations off the top of my head (which are quick
examples).

Such as?  Do you have an example of a scenario in which there's a benefit  
of doing some cleanup early, removing objects that the threads need to  
use, and then still waiting on the threads to complete?

I'm sure people run into better (more relivant) situations
naturally, but for example say you want to Restart
(Application.Restart()) the application, or do something else (in the
case of some kind of error, or special event), the user may very of
well been the one to signal the "okay get on with it, I don't care
what threads are doing I want to do something else now", then the user
surly doesn't want to wait for any threads, so you clean up what you
can really quick, set the violet flag to tell the threads to finish,
and start the next task (letting the threads finish gracefully in the
background).

But that's not a correct design, if the threads may want to use any of the  
data structures you are cleaning up before they complete.

You could certainly design an application such that the entire context for  
a session is replaced when restarting, where none of the previous context  
is cleaned up until the threads are done.  But then you're basically  
waiting for the threads to finish anyway, which is what I said you need to  
do.

You simply cannot have valid code in which you clean up data structures  
that threads that continue to run may need to use.  Your only choices are  
to wait for the threads to complete before cleaning up the data structures  
(either letting them run to completion or telling them to interrupt  
themselves), or to change the design so that those data structures are not  
needed by the threads.

Any other design is flawed.

If not, then you need to design the thread to be interruptible.  That's
not a problem.

Sometimes, for quick applications at least, re-designing your own
ThreadPools, or such, to fit your situtation perfectly isn't
acceptable (time wise).

Irrelevant.  That's not what I'm suggesting anyone do.

Instead they use the one already made and
live by the limitations of that implementation, or work around them.

I don't feel that a coder really has a choice with respect to writing  
correct code.  No programmer deserving of that label has any business  
intentionally writing code that they know to be defective.

Pete

Correct code is in the eye of the beholder. Just because your design
has some limitations or work-arounds doesn't make it defective.

But that's not a correct design, if the threads may want to use any of the
data structures you are cleaning up before they complete.

Who says the threads want to use any of the data structures you are
clenaing up. Furthermore, there is a "disposed" at their disposal.
if(!disposed) use structure.

I always read that ThreadPool threads are lightweight; using them like
suggested isn't correct (design wise as you say). If someone is using
it like that then they probably should redesign the solution to not
use the ThreadPool :P

NB
.

Relevant Pages

  • Re: ReaderWriterLockSlim + Dispose?
    ... volatile flag. ... Do you have an example of a scenario in which there's a benefit of doing some cleanup early, removing objects that the threads need to use, and then still waiting on the threads to complete? ... But that's not a correct design, if the threads may want to use any of the data structures you are cleaning up before they complete. ... You could certainly design an application such that the entire context for a session is replaced when restarting, where none of the previous context is cleaned up until the threads are done. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How competent are we?
    ... Changes in file layout are easy if IO is isolated in called programs. ... FOR EACH BRANCH in an array. ... That wouldn't happen if data structures had been designed in normalized form from the ... design should be top down. ...
    (comp.lang.cobol)
  • Re: interesting
    ... It's too hard to adequately specify ... And as complexity increases, the "software entropy" curve ... > data structures can make an early entrance into the design ... Data structures are about implementation. ...
    (sci.electronics.design)
  • Re: Real world musings
    ... > books at the time, ... > expressive than good old data structures and functions. ... and design, only to find out that the designs were overly broad, had ... with code-centric development processes. ...
    (comp.object)
Loading