|
The ASPSmith |
|
|
| D: | Domains | Authors.aspalliance.com | Stevesmith | Articles | Static Methods and Threads |
|
Static Methods and Threads In the .NET Framework, it is possible to create methods (and properties) of Classes that are shared by all instantiated members of the Class. In C#, these methods and properties are declared with the static keyword. Using this technique, it is possible to reference a method or property without ever instantiating the class, which makes for much simpler code. For instance, to reference a connection string on a class named DAL in the ASPAlliance namespace, you would use this: string connString = ASPAlliance.DAL.ConnectionString; However, if a non-static property were used, you would have to do this: ASPAlliance.DAL myDAL = new ASPAlliance.DAL; string connString = myDAL.ConnectionString;and, further, the myDAL instance of the class is now taking up resources until it is garbage collected. Of course, the static methods require resources as well, but there is only ever one instance of a class's static properties and methods in memory at a time, while there could be many instances of a class and its non-static properties and methods at any point in time. Ok, so if the benefit of static methods and properties is that they only exist in memory in one place at any time, does that mean that they are single threaded, and could therefore be a bottleneck? No. As it happens, static methods handle threading issues just fine, as this sample application demonstrates. If the static method were single threaded, it would be instantiated by one thread and then would continue to execute (forever) only on that thread. However, as you will see when you run this sample, the static method does in fact get executed by multiple threads. Now, of course, for this application only one line of output can be displayed at a time, so naturally there is an altnernation pattern between thread 1 and thread 2. But the point is, if static methods were tied to a particular thread, there would be no alternation, and you would only see a single thread throughout the execution of the function. // This application demonstrates that static methods // are multi-threaded, and thus will not present a // thread-locking bottleneck when used in a highly // multi-user environment. // // Authors: Mitch Denny and Steven Smith // // Tested with .NET Beta 2, CLR v1.0.2914 // // Compile with: csc /r:System.DLL /out:ST.exe StaticThreads.cs // using System; using System.Threading; public class StaticThreads { public static void Main() { Thread myThread1 = new Thread(new ThreadStart(StaticThreads.DoSomething)); Thread myThread2 = new Thread(new ThreadStart(StaticThreads.DoSomething)); myThread1.Name = "Thread 1"; myThread2.Name = "Thread 2"; Console.WriteLine("Press ENTER to start,"); Console.WriteLine("and ENTER again to stop."); Console.ReadLine(); myThread1.Start(); myThread2.Start(); Console.ReadLine(); myThread1.Abort(); myThread2.Abort(); } public static void DoSomething() { while (true) { Console.WriteLine(Thread.CurrentThread.Name); } } } This may have been obvious to some of you, but I wasn't sure if somehow static methods were fundamentally different from non-static methods, and this little example was how I determined how things really work in .NET. Here are some comments from Max Poliashenko that may help clear up some confusion about threads and class or static methods: Steve, how can a method be single threaded? It is just a method and can be called by multiple threads independently, unless you use special thread synchronization mechanisms to prevent that. There are no multiple instances of class methods for non-static methods, like you suggest in your article. There is only one copy of any method residing in assembly. A method, static or not has nothing specific to the object instance. The only difference between static and non-static methods is that static methods do not have "this" pointer silently passed to them, like non-static methods do. In fact, static and non-static methods deal with multithreading in the same way - they are open to be called from any thread that wishes to do so, they don't care, unless you put code inside that cares about it. I think, you may be confusing VB objects and OO objects. VB objects are COM objects and they are separate DLL or EXE units that can be loaded in multiple instances and in fact, can synchronize threading access to them via COM mechanisms, so it makes sense to talk about single-threaded COM components and thus VB objects, but in .NET and C++, there is no such a thing as single-threaded or multi-threaded class. Classes and methods can only be thread-safe or not, but this is completely different story. Regards, Max. |
|
|
|
|
|
|