Mike, all fine examples of ignorant programmers doing things
that affect
your program. Bar the first one, none really stem from you
providing a
public interface prone to having a correctable problem.
The other difference is there's really not much you can do
about those
situations. Arguably, sure, you could spin up another
thread to service
points one; but...
Now, I'm not suggesting everyone go out and hunt down all
cases of "lock
(this)" (or "lock(typeof(...", etc.) unless
they have known intermittent
hanging problems.
But, instead of writing lock(this) and writing:
private Object lockingObject = new Object();
public void Method()
{
// ...
lock(lockingObject)
{
//...
}
//...
}
...is a no-brainer workaround.
I haven't talked to anyone who thinks lock(this) or lack
thereof is
magical. Although, I wouldn't be talking to them much
longer after that :-
). None of the references suggest "lock(this)"
causes deadlocks they
detail they "may" be the cause deadlocks. If
they've misread the text and
have gone the "voodoo programming" route, you're
doomed anyway.
> In response to me firing an event defined on my public
interface, to
which my
> client has subscribed, said client's callback displays
a modal dialog box
> requesting user input. Said user is getting coffee at
the time.
>
> * They queue up more than 24 requests to the thread
pool that call
methods
> which hang out waiting for stuff to get done. This
doesn't even involve
> touching my interface, but if my component relies on
threads from the
thread pool, I'm now in trouble.
>
> * The client opens a named mutex my component uses
internally for cross-
process
> synchronization, and fiddles with it.
>
> * The client starts a thread that proceeds to use
inordinate amounts of
CPU
> time. At best, this slows down the ability/willingness
of the thread
pool
> manager to dispatch pooled threads to handle pending
requests. At worst,
> the CPU is pegged to the degree that the thread pool
manager refuses to
> dispatch further work requests until the cpu settles
down. Again, the
> client isn't doing anything to my interface directly,
but if my component
> relies on the TP to get my job done, I'm in trouble.
>
> * Even though I implement IDispose, the client didn't
leverage the using
> construct, nor did they use try/finally on their own to
ensure that they
> called my Dispose method. And they kept a reference to
my public
interface
> stored in a static field (directly or indirectly), so
my finalizer (if I
even
> have one) can't kick in an clean up the mess. They've
only used my
public
> interfaces, but their use of my public interfaces isn't
playing very
nicely.
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
|