synchronisation refers to the practice of ensuring that only one thread executes in a section of code at a time. While discussion of all of them is beyond the scope of this article, a surprising number of constructs must take place inside a single threaded block to be reliably safe. Unfortunately, most of them work fine almost all of the time if outside of such a block, so the old "If it compiles and I get the answer I expect, it's right" mantra doesn't hold here. This is part of why multithreading is so dangerous. A monitor is the most basic synchronisation construct. Any object can have a monitor associated with it, and no monitor can be associated with more than one object. Monitors have a "lock," which may be acquired by only one thread at a time. It must be released by that thread before another thread can acquire it. You can guard a section of code by declaring an object that is visible to all threads, such as a class field, and having a section of code acquire the lock from that monitor before performing some operation and then release the lock when it completes. This construct is demonstrated in Listing E.We declare an object, myLockObject, whose sole purpose is to provide a monitor for synchronisation. In the SayHello method, we allow both threads to print "Hello" whenever they want. However, we control the printing of "Wonderful" and "World" with a monitor associated with myMonitorObject so that one thread must complete both prints before another is allowed to begin. Two other techniques are available for accomplishing this mechanism -- the lock() keyword and the MethodImplAttribute attribute. See Listing F for an example.We replace the Monitor.Enter(...) and Monitor.Exit(...) constructs with a lock(...){ ... } construct. These constructs are identical in effect -- the latter is simply shorthand for the former. We also add a method, SayHello2(), which has an attribute attached to it, MethodImpl. This attribute specifies that the entire method is to be synchronised. This is equivalent to forcing the calling code to acquire a lock on the monitor associated with the type object that contains the method before it is allowed to make the call. This is cleaner than enclosing the method body in a lock(){...} statement. Note that the documentation defines the attribute as being called MethodImplAttribute, but its implementation has it called MethodImpl instead. According to the stated convention for declaring attributes, it appears that a developer at Microsoft may have goofed. Summary
This article has covered a lot of ground. I have discussed the reasons for and against explicitly using multiple threads, as well as shown some of the primitive constructs you will need if you choose to do threading. I introduced the Thread object and explained how to run several threads to accomplish the task of your choice. I described the monitor concept and showed how to use it to achieve synchronisation around a block of code. I also described two shorthand means of accomplishing the same thing in specific cases, the lock keyword and the MethodImpl attribute. In future articles, I will describe several other basic constructs, implement a thread pool, and explore more advanced constructs, such as thread-local storage and overlapped I/O.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
