VS 2005 thread safety issue regarding HashTable and other objects.

[Randolph Neall]

In VS 2005 do multiple threads and multiple writers impair a hashtable to
the extent that an actual exception would be thrown? Or, on the contrary, do
you simply get a badly-written hashtable? We are trying to track down why a
C# windows service program we've written exits--we're assuming because of an
uncaught exception somewhere. We do have some cases in this program where
we've not synchronized hashtable access, and wondered whether this would be
a candidate explanation for a windows service that dies and disappears.

More generally, does one get an exception when multiple threads hit a
non-thread-safe object, or does one rather simply get inconsistent values
within that object, with no exceptions thrown? We are aware of exceptions
that happen when two uninvoked threads hit a windows form-related object,
but what about non-form objects, such as hashtables or objects we might have
written, or objects containing static methods?

Thanks,

Randy Neall

 

[Carl Daniel [VC++ MVP]]

In VS 2005 do multiple threads and multiple writers impair a
hashtable to the extent that an actual exception would be thrown? Or,
on the contrary, do you simply get a badly-written hashtable? We are
trying to track down why a C# windows service program we've written
exits--we're assuming because of an uncaught exception somewhere. We
do have some cases in this program where we've not synchronized
hashtable access, and wondered whether this would be a candidate
explanation for a windows service that dies and disappears.

More generally, does one get an exception when multiple threads hit a
non-thread-safe object, or does one rather simply get inconsistent
values within that object, with no exceptions thrown? We are aware of
exceptions that happen when two uninvoked threads hit a windows
form-related object, but what about non-form objects, such as
hashtables or objects we might have written, or objects containing
static methods?

When multiple threads attempt to modify an object that's not threadsafe
you're likely to get inconsistent state, and inconsistent state could
certainly lead to an exception being thrown by some member function of the
class at some point in the future.

If you're accessing an object from multiple threads without proper
synchronization, just about anything could happen as a result.

-cd

 

[Randolph Neall]

Thanks, Carl.

One more question: is an uncaught exception more likely to cause an
application to exit (such as aborting with a fatal error) than is a caught
exception?

We're not only trying to figure out what might be causing the exceptions,
but also what type of exception it would have to be to cause the service to
be terminated by the operating system (Windows Server 2003).

What is the best global way to catch exceptions in a non-windows forms
application?

Randy

 

[Randolph Neall]

After further research, it appears that catching exceptions can help keep an
application from terminating in some cases but not in others.

Randy