Basic question about threading.

[GeezerButler]

Hello all,
I am completely new to threading and am sorry if this sounds stupid.

I am developing a class which extends from ApplicationException class.
Basically this class (MyException) captures local and instance
variables and method parameters at the time of exception. This
exception is then propogated upwards and goes on collecting the above
mentioned information of all the method/classes through which it
bubbles.
For this purpose i have a "Dictionary<string, Snapshot> methodStates"
in MyException which holds all the information.
Finally i override the ToString method of ApplicationException to
provide a nice view of all the data that my class contains.

Anyway, now since ApplicationException is not thread safe
1)Does this mean that MyException is also not thread safe even if i
lock methodStates collection whenever i access it? Is it that, if
BaseClass is not threadSafe then DerivedClass cannot be thread safe no
matter what you do.
2)Will the locking of the methodStates make sure that atleast my
dictionary is thread safe?
3)What is it that makes ApplicationException not thread safe? From my
limited knowledge, i know that a class with a mutable state is
considered not thread safe.

Basically i want to know if all the care that i am taking to lock my
dictionary is worth anything at all.

Any kind of help would be greatly appreciated.

 

[Peter Duniho]

[...]
Anyway, now since ApplicationException is not thread safe
1)Does this mean that MyException is also not thread safe even if i
lock methodStates collection whenever i access it? Is it that, if
BaseClass is not threadSafe then DerivedClass cannot be thread safe no
matter what you do.

You cannot make the inherited members of the base class thread-safe,
unless they are overrideable. If they are overrideable, then you can
override them, providing the necessary locking to make them thread-safe.
You can also provide thread-safe versions of the accessors, so that at
least when code knows it's trying to use the class in a thread-safe way,
it can. Finally, of course anything new you add can be made thread-safe.

2)Will the locking of the methodStates make sure that atleast my
dictionary is thread safe?
Yes.

3)What is it that makes ApplicationException not thread safe? From my
limited knowledge, i know that a class with a mutable state is
considered not thread safe.

"Thread-safe" refers to the question of whether two different threads can
safely access the class data (or other data) without worrying about
synchronizing access with each other. This can happen either because
there's nothing in the class that would cause a conflict, or because the
class itself handles all of the potential synchronization issues.

Basically i want to know if all the care that i am taking to lock my
dictionary is worth anything at all.

Do you expect to be using the class instance from multiple threads, where
each thread may attempt to access the same data as another thread at the
same time? If so, then you need to ensure that access to the data is
synchronized. In the case of your Dictionary<> instance, this means
locking it (in the most basic case). You may find that you also need to
synchronize access to the MyException class instance as well, to ensure
that other inherited members are accessed in a thread-safe way.

Note that if you don't access the class instance from multiple threads,
then the fact that it's not thread-safe is not a problem at all.

Finally, all of the above relates to instance members of a class. If you
have static data members, similar issues apply, except that you can run
into thread-safety issues even though you never access the same instance
from multiple threads.

Pete

 

[GeezerButler]

[...]
Anyway, now since ApplicationException is not thread safe
1)Does this mean that MyException is also not thread safe even if i
lock methodStates collection whenever i access it? Is it that, if
BaseClass is not threadSafe then DerivedClass cannot be thread safe no
matter what you do.

You cannot make the inherited members of the base class thread-safe,
unless they are overrideable. If they are overrideable, then you can
override them, providing the necessary locking to make them thread-safe.
You can also provide thread-safe versions of the accessors, so that at
least when code knows it's trying to use the class in a thread-safe way,
it can. Finally, of course anything new you add can be made thread-safe.

2)Will the locking of the methodStates make sure that atleast my
dictionary is thread safe?
Yes.

3)What is it that makes ApplicationException not thread safe? From my
limited knowledge, i know that a class with a mutable state is
considered not thread safe.

"Thread-safe" refers to the question of whether two different threads can
safely access the class data (or other data) without worrying about
synchronizing access with each other. This can happen either because
there's nothing in the class that would cause a conflict, or because the
class itself handles all of the potential synchronization issues.

Basically i want to know if all the care that i am taking to lock my
dictionary is worth anything at all.

Do you expect to be using the class instance from multiple threads, where
each thread may attempt to access the same data as another thread at the
same time? If so, then you need to ensure that access to the data is
synchronized. In the case of your Dictionary<> instance, this means
locking it (in the most basic case). You may find that you also need to
synchronize access to the MyException class instance as well, to ensure
that other inherited members are accessed in a thread-safe way.

Note that if you don't access the class instance from multiple threads,
then the fact that it's not thread-safe is not a problem at all.

Finally, all of the above relates to instance members of a class. If you
have static data members, similar issues apply, except that you can run
into thread-safety issues even though you never access the same instance
from multiple threads.

Pete

Thanks for such a detailed explanation.
Super appreciated!