Re: synchronizations of threads
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sun, 19 Oct 2008 16:44:58 -0700
On Sun, 19 Oct 2008 14:48:35 -0700, puzzlecracker <ironsel2000@xxxxxxxxx> wrote:
[...]
SO my question is why do we need need workLock, can we just use
workQueue to synchronize the access to the queue and manage the
execution of threads in the pool?
Is that really the code directly from the book, verbatim? What edition of the book are you looking at?
To answer your immediate question, it's not the lock using workLock that's superfluous, it's the lock using workQueue. In fact, IMHO the lock using workQueue shouldn't be used at all. As has been discussed elsewhere, including in Jon Skeet's web article on threading, using a privately allocated instance of Object for a lock is preferable to using the object that actually needs the synchronized access, because doing so ensures that only that particular code is locking on that particular object.
At the very least, using a "public" reference (that is, a reference that some other code might see, whether the variable itself is public or not) runs the risk of increased contention, and it even slightly increases the risk of having a deadlock bug.
In this particular context, I see no value at all in the inner lock. The code is already synchronized with the other code in the example that touches the object and that's sufficient.
Now, that said, that's not the only, or even most serious problem I see with the code. I am surprised to see the non-generic Queue class being used, but more significantly the use of the "stop" variable to signal a shutdown rather than just communicating through the queue, which leads to the two-second timeout, another questionable design choice, and the fact that the workLock lock is held during the entire execution of the worker delegate (imagine if the .NET ThreadPool class blocked any thread trying to queue a work item until _all_ currently queued and executing tasks were done), these are all bad problems IMHO.
In other words, I'm not sure I'd use this kind of code as a way to learn about how best to implement threaded code. It has the scent of being written by someone who knows just enough to be dangerous.
Interestingly, Jon reviewed this book and while he did have some observations about the threading examples, he didn't have any particular comments about that example. I don't know whether that's because Jon thought the queue example was fine, or he just thought his point about the weakness in Nash's presentation on threading was made well enough with the example he did comment on, but if the former that might mean I've overlooked something that justifies the implementation is it is. I don't think I did, but you never know. :)
Pete
.
- Follow-Ups:
- Re: synchronizations of threads
- From: puzzlecracker
- Re: synchronizations of threads
- References:
- synchronizations of threads
- From: puzzlecracker
- synchronizations of threads
- Prev by Date: Re: DateTime Null
- Next by Date: Re: DateTime Null
- Previous by thread: synchronizations of threads
- Next by thread: Re: synchronizations of threads
- Index(es):
Relevant Pages
|