Re: ReaderWriterLockSlim + Dispose?

On Sat, 05 Apr 2008 11:17:01 -0700, NvrBst <nvrbst@xxxxxxxxx> wrote:

[...]
In that particular example, you either need to decide whether you're going  
to interrupt the threads that need the lock, or you're going to delay  
cleanup of the lock until the threads are all done.  You can't let the  
threads run _and_ clean up the lock right away.

Aye. I understand this design wise, but, in the case of the thread
pool, you can't interrupt it.

Of course you can. Not that I was suggesting you use Thread.Abort(), but even that should work okay (exceptions are eaten by the thread pool, but your own code is aborted...the thread pool will just create a new thread later if needed). In reality, if you need a thread (thread pool or otherwise) to be interruptible, you just design it to be so. Use a volatile flag, have the code in the thread check the flag and exit when it can. Or any of a number of other signaling mechanisms that are available.

And waiting around for the threads to
finish isn't always a perferred solution;

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

maybe the locks were there
to syncronize actions (IE in the case of a chat program, the thread
could lock the send/recive method on a line basis, so if you stop
locking the worst that could happen would be something like Msg1:
"hello jim." Msg2: "test", resulting in "hetleslo jim .\nt".

If I were using a messaging application that produced a result like that, I would never ever run it again. At the very least, it suggests that the provider of that application was willing to let less-than-perfect behavior occur just to make their own life simpler. And worst, it's a strong clue that the provider may have underestimated the need to produce correct code.

Synchronization exists to ensure correct, predictable behavior from the code. If the code isn't synchronized and is allowing output to be intermingled when that wasn't part of the user's intent, who knows what else may have been overlooked by the provider?

If your
cleaning up, your probably not caring what else the threads going to
do as long as it doesn't crash, etc.

Well, first of all...the "as long as it doesn't crash" is an important consideration: how can you prove that your code won't crash if you've abandoned synchronization? Secondly, if you're cleaning up, then either it's okay to interrupt the threads or it's not. If it is, then you design those threads so that they can be interrupted and then you interrupt them. If it's not, then you have no choice but to wait for them to finish. 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?

Pete
.

Relevant Pages

  • Re: Hello All
    ... section to be used as INTERRUPT PROCEDURE. ... You would normally use more than one INTERRUPT PROCEDURE when you have more than one event that you want to trigger a software interrupt. ... The requirement to lock master records before detail records is controlled by the LOCK TO MODIFY DETAILS option in DASDL. ... It is specified on the master data set. ...
    (comp.sys.unisys)
  • Re: ReaderWriterLockSlim + Dispose?
    ... cleanup of the lock until the threads are all done. ... pool, you can't interrupt it. ... volatile flag, have the code in the thread check the flag and exit when it   ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: race on multi-processor solaris
    ... > want to block if the lock holder is not running. ... and there is a CPU structure for each CPU. ... interrupts") are handled by "interrupt threads", ... Before we set the waiters bit, we grab the lock protecting the lock's ...
    (comp.unix.solaris)
  • Re: [RFC PATCH] Fair low-latency rwlock v5
    ... If the lock is uncontended, but is not in the current CPU's caches, ... Fair low-latency rwlock provides fairness for writers against reader threads, ... but lets softirq and irq readers in even when there are subscribed writers ... Added contention delays performance tests for thread and interrupt contexts to ...
    (Linux-Kernel)
  • Re: RT patch acceptance
    ... > I really dislike the idea of interrupt threads. ... it isn't possible to do all of this per path and lock in any sane manner. ... This extends to all of the drivers in Linux as well. ... > Of course you would not do it as a big patch. ...
    (Linux-Kernel)
Loading