Re: ReaderWriterLockSlim + Dispose?

On Sun, 06 Apr 2008 11:39:30 -0700, NvrBst <nvrbst@xxxxxxxxx> wrote:

On Apr 6, 11:20 am, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
You did.  You specifically said you are talking about cleaning up  
synchronization data structures that are used by the threads.

I think you miss read some place, I've never used the word data
structures anywhere here,

You don't need to use the phrase "data structure" to be talking about a data structure. The ReaderWriterLockSlim class is a data structure.

Rather than going through the rest of your post point by point though, I think the most productive thing is to focus on this:

[...]
I walk talking about this. To be more specific, basically I said that
if I have a solution that cleans up the object immediatly, lets all
the threads gracefully exit on their own, and doesn't affect the user
(visually) any bit, then not only is this a correct design, but its
more elegant in the respect of using the "disposed" variable as a
violet flag (which, intuativaly, gets checked - and can immidatly exit
the thread when it is checked and found violet).

First of all, I think the word you want is "volatile". Secondly, what does that have to do with the paragraph I quoted in which you discussed the use of the thread pool?

That said, let's ignore the non-sequitur for the moment and focus on what you did write. I note, by the way, that you have changed your suggestion so that your threads now exit when they note the synchronization object as being disposed, rather than simply continuing to process without the benefit of synchronization as you suggested earlier. For what it's worth, that doesn't actually change the reality of the situation though. You still need to wait for the threads to exit (or at a minimum, to signal back that they've acknowledged the "exit early" signal).

In particular...

Unless your Dispose() method is thread-safe (this is true for ReaderWriterLockSlim, but that class has no way to check whether it's actually disposed, so you must be talking about some other class), you cannot reliably check the disposed state as a way of knowing whether it's safe to use the synchronization object. For some other class to be thread-safe, you need to introduce some thread synchronization. Otherwise, one thread could be just about to dispose the synchronization object, but not yet have set the "disposed" flag, while another thread is about to try to use the object that's about to be disposed (having already checked the flag). If the latter thread now gets preempted and the first thread gets to run and dispose the object, the second thread is screwed when it eventually gets to run again.

So, either you introduce a new volatile flag to indicate that the threads need to exit and not dispose your synchronization object until the threads have exited (in which case that's exactly the "signal the thread to exit" design I said was one legitimate way to address the issue), or you have to add a new synchronization object to the design to protect the retrieval of the dispose state (in which case, now you have to wait for all the threads to exit before you can dispose _that_ synchronization object).

In other words, you have a paradox in your argument that always leads to creating a design that is exactly as I suggested it needs to be in the first place: you either need a signal to the threads to get them to stop processing, or you need to simply wait until they're completely done. Either way, you can't clean up until the threads are all done.

If you like, feel free to post a concise-but-complete implementation that does what you think is okay, using a disposable synchronization object that your threads make use of as you've described above. I will be happy to point out in that concrete example the scenario in which your threads fail to produce correct behavior (whether because they simply don't produce synchronized output, or they actually crash trying to use a disposed object).

Pete
.

Relevant Pages

  • Re: Dispose pattern in multithreaded application
    ... I have a question on handling Dispose() in an application I wrote. ... Since there are callback methods in the classes, If I have a class A ... In every method, lock a disposeLock object, check if disposed flag ... Normally that synchronization would address the dispose issue as well, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Dispose pattern in multithreaded application
    ... I have a question on handling Dispose() in an application I wrote. ... In every method, lock a disposeLock object, check if disposed flag ... Normally that synchronization would address the dispose issue as well, and often may not even be part of the implementation of the disposable class itself. ... Of course another question is whether the classes you are concerned with being disposed during the callback is the class implementing the callback or the one calling it. ...
    (microsoft.public.dotnet.languages.csharp)
Loading