\[~ann.campbell.2] Based on [~dinesh.bolkensteyn]'s comments I've changed the description a bit. Also, with this wording it is more like a bug than a maintainability issue. So I've modified the severity as well. I didn't change the SQALE characteristic, do you see any better option?
\[~tamas.vajk] as written, 'Critical' is not currently appropriate for this rule. If we're going to increase the severity, then the description needs to show why it's 'Critical'. What mistakes will this misunderstanding have lead the developer to make?
\[~ann.campbell.2] I can understand that you couldn't find a lot of info on ``++ThreadLocal++``. It is only part of .Net 4, and it is probably rarely used.
If you have a ``++ThreadStatic++`` non-``++static++`` field, that behaves as a normal non-``++static++`` field. So the attribute is useless on it. You should remove it (first compliant solution). But what if you want a non-``++static++`` field that can store different values based on the thread we are using it from. Then you can use the ``++ThreadLocal++`` class (second complaint solution).
Check out the below code:
----
var m1 = new MyClass();
var m2 = new MyClass();
m1.Count = 5;
m2.Count = 7;
Task.Factory.StartNew(() =>
{
m1.Count = 6;
m2.Count = 8;
Console.WriteLine(m1.Count);
Console.WriteLine(m2.Count);
}).Wait();
Console.WriteLine(m1.Count);
Console.WriteLine(m2.Count);
----
It writes to the console ``++6,8,5,7++``. We have two instances of ``++MyClass++``, we set the ``++Count++`` to different values (the field is not static). Then start a new thread, and set the ``++Count++`` again to different values. In the new thread and in the main thread the ``++Count++``s have different values even for the same objects.
