Re: ReaderWriterLockSlim + Dispose?

On Apr 4, 10:28 pm, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
I can't say whether you're missing something.  I do know that a quick  
Google search yielded this link:http://blogs.msdn.com/vancem/archive/2006/03/29/564854.aspx

:) I did see that page before when searching "RWLS + dipose", it was
the only page that showed up on the first google results page that had
relavance. Aye, its not the ReaderWriterLockSlim class, but the
comments at the bottom did give me suspecions that cleaning up RWLS's
might not be needed that much.

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. And waiting around for the threads to
finish isn't always a perferred solution; 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 your
cleaning up, your probably not caring what else the threads going to
do as long as it doesn't crash, etc.

This example stores the instance in a static variable, so IDisposable
wouldn't apply.

Ahh. I always through using static on IDisposable objects was a no
no. But yes, I see now that if the IDisposable object is living to
the end of the application (which is the case of my RWLS's usally),
making them static would simplify my code a lot, and might be the
intended way of using them most the time. I'll look into this
approach more at the very least :)

Thanks for your comments, they were helpful. I usally use Monitor's
(+lock statments) anyway, but wanted to try a few applications with
RWLS and think static might be the way to go for some of the problems
I had with them.

NB
.

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: 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)
  • Re: Locking netatm
    ... Interrupting the code while getting a lock could result in a race condition. ... If you have to protect datas through a TSL ... by interrupt timer and threadB is scheduled to run. ... want to receive interrupts until the netatm memory for the ...
    (freebsd-arch)