[Webmethod]
Public static string GetAge(List<int> input1, string input2)
{
Cust cu=Cust.CalAge(input1,input2)
cu.agemodify=true;
}
An AJAX call calls this Webservice.
CalAge is a static method inside class Cust.
agemodify is a boolean field inside class Cust.
List<int> is thread safe as a parameter
to a static method because for int, immutability doesn't apply. Is
that correct? I know list <T> isn't threadsafe. What about just
<T>s as parameters if T is immutable or Objects if they are
immutable? e.g. public static int GenMethod<TFirst,TSecond>(),
GetMethod(List<object> o1, object o2). Just Object vs
List<Object>. I don't want to use System.Collections.Concurrent.Unfortunately, your question is bordering on being too broad. You seem to be conflating several different and completely unrelated concepts, as if they somehow relate to each other in a meaningful way even though they don't. I'm skeptical that in the context of a Stack Overflow answer, it would be possible to unravel all of the misconceptions represented here.
That said, I'll make a try. At the very least, I hope that with the below, there is enough information that you can go back to review the primary sources (e.g. MSDN, other documentation) and correct your understanding. In the best case, perhaps the below is sufficient to get you entirely back on track.
- I understand that all non static fields/local variables have different copies on the stack per thread even in a static method. Is that correct? So these are thread safe and are not shared resources. agemodify is therefore thread safe?
"Is that correct?" — No. It's borderline gibberish. A local variable declared in a method has a new instance, and hence a new copy of whatever value was passed or initialized in the method, for each call to the method. So, yes in the case of the local variable, each time the method is called in different threads, there are new copies, but this has nothing to do with the threads. It's all about the method call.
As for non-static fields, these may or may not be stored on the stack†, so any conclusion based on an assumption that they are stored on the stack is necessarily wrong. For reference types you only get a new copy for each instance of the object. For value types, you get a new copy of each field for each instance of the value type as well, but since you get a new instance of the value type each time it's assigned to a new variable, there can be many more copies. But again, nothing to do with threading, and nothing to do with the stack (since value types can exist either on the stack on the heap).
"agemodify is therefore thread safe?" — There is not enough code to answer that question. You would need to provide a good Minimal, Complete, and Verifiable code example for anyone to answer that definitively. If the Cust type is a reference type, and the CalAge() method always creates a new instance of the type, or the Cust type is a value type, then I would say that yes, the field is thread safe.
Otherwise, not necessarily.
† For that matter, that local variables are stored on the stack is just an implementation detail. It's not likely to change for regular local variables, but there's no requirement in C# that they be handled that way. They could be stored anywhere, as long as the compiler preserves the semantics of a local variable, and indeed this is exactly what happens in a variety of contexts in C#, such as captured local variables, and local variables found in special methods like iterator methods and async methods.
- My understanding is that
List<int>is thread safe as a parameter to a static method because forintimmutability doesn't apply. Is that correct? I knowList<T>isn't threadsafe. What about just<T>s as parameters if T is immutable or Objects if they are immutable? e.g.public static int GenMethod<TFirst,TSecond>(),GetMethod(List<object> o1, object o2). JustObjectvsList<Object>. I don't want to useSystem.Collections.Concurrent.
Again, all that mostly doesn't make any sense. The value of the input1 variable, being a local variable, is inherently thread safe because a new copy exists for each call to the method. But that's just the variable. The List<int> object itself is not affected by this at all, and is decidedly not thread-safe. Only if each thread executing the method gets a unique instance of the List<int> object could you say that would be thread-safe.
As for values of a type parameter T go, there is nothing about generics that would make these inherently thread-safe. As far as thread-safety is concerned, T is just another type. The fact that you don't know the type when the generic type or method is compiled is irrelevant, and does not in any way help make values of that type thread-safe.
- My understanding is that because Webmethod is static, any classes further down the stack need not be instantiated, and therefore, might as well be static because there will only be one Webmethod "instance" throughout. Is that correct? Is it better to have a dedicated webservice (wcf/asmx) wrt thread safety instead of static webmethods on an aspx page?
Sorry, more mostly meaningless combinations of words. What is meant by "classes further down the stack"? If you call a method that needs to use a string value, for example, do you really think that means you get to use some mythical static version of the string type, just because the caller is static?
No, the rules about what needs to be static and what doesn't don't have much to do with the caller. The only thing the caller affects is that a non-static caller wouldn't need to provide an explicit instance reference to use other non-static members in the same class, because there's an implicit this reference in that context. Otherwise, a static method calling instance members still needs an instance reference. And if you can make members that the static method uses also be static, that is better because then you don't have to provide that instance.
But just because the caller itself is static, that doesn't automatically mean you get to avoid instantiating objects within the call context. If you need to access instance members of some type, you'll still need an instance of that type.
As far as the web service-specific stuff goes, that all depends on the nature of the values being used in your method. There's not enough context in your question to provide any sort of definitive discussion regarding that.