VB.NET threading

A Brief Recap

To the spinning wheel

• Use the Thread class
  Dim someThread As New Thread(AddressOf SomeMethod)
someThread.Start()

  This spawns a totally new thread, executing the code inside the SomeMethod method (which you define yourself). Don't forget that second line of code or else the thread will never start running and you'll be spending hours trying to figure out why (first-hand experience here). Also note that you could also do something like this:
  
  Dim someClass As New SomeClass
Dim someThread As New Thread(AddressOf someClass.SomeMethod)
someThread.Start()

  This will spawn a thread which runs inside the individual instance of that class.
   
• All yarn outta the pool
  Dim someObject as New Object
ThreadPool.QueueUserWorkItem(AddressOf SomeMethod, someObject)

  The ThreadPool class is basically a list that manages up to twenty-five different threads. All threads the pool have a priority of "normal" (I'll explain more about that soon), which cannot be changed. From what I've read, it's suggested that you use this technique instead of the latter unless you're desperate for more control over your code.
   
• Note: Thread is NonInheritable
  For any Java programmers out there, VB.NET does not allow you to create a class which inherits Thread. Being from a Java background myself, this absolutely bedazzled me.

"It's either the car or ME!"

Left, one two three, right one two three

1. Dim lockObject As New Object
Sub SomeMethod()
     SyncLock lockObject
          'critical section goes here
     End SyncLock
End Sub

   This is the simplest way of accomplishing synchronization. The lockObject must be (1) not equal to Nothing and (2) a reference object (i.e. not a primitive like Integer or Double).
    
2. Imports System.Runtime.CompilerServices
Class SomeClass
     <MethodImpl(MethodImplOptions.Synchronized)> _
     Sub SomeMethod()
          'critical code
     End Sub
End Class

   The mess of code you see above makes the entire method synchronized. It's just like encasing all the method's code in a SyncLock block, but without having to declare a special object to act as the lock. If you have multiple methods in the same class using this, they each share the same lock object behind the scenes so only one of the synchronized methods can be accessed at a time.
    
3. Imports System.Runtime.Remoting.Contexts
<Synchronization()> _
Class SomeClass
     Inherits ContextBoundObject
     'everything is critical!
End Class

   This makes everything inside your entire class critical, which is nice if you want an easy way to avoid synchronization bugs. However, from what I've read, that's usually overkill. Plus, you're forced to inherit some stupid object.

1. Dim lockObject As New Object
Monitor.Enter(lockObject) === SyncLock lockObject
Monitor.Exit(lockObject) === End SyncLock

Dim lockObject As New Object
Sub SomeMethod()
     If Monitor.TryEnter(lockObject) Then
          Try
               'you've obtained the lock and have entered the critical section
          Finally
               Monitor.Exit(lockObject)
          End Try
     Else
          'No lock for you!
     End If
End Sub

   The Monitor object contains all the functionality of the SyncLock block plus an additional feature. The TryEnter() shared method returns True and acquires the lock if the lock can be acquired or False if the lock cannot be acquired (it will not wait to acquire the lock like the Enter() method does).
    
2. Dim lockCounter As Integer
Sub SomeMethod()
     Try
          If Interlocked.Increment(lockCounter)                'critical section
          Else
               'there are more than four threads in the critical section...no lock for you!
          End If
     Finally
          Interlocked.Decrement(lockCounter)
     End Try
End Sub

   This class acts like Monitor.TryEnter() in that it will try to obtain the lock, but won't wait for it. What is unique here is the fact that you can control just how many threads are allowed to access the critical section. The example above allows a max of four threads inside at once. Since you're only incrementing and decrementing an integer, I don't know why you need an entire class to do this, but I could be missing something.
    
3. Dim someMutex As New Mutex
Dim lockObject As New Object
someMutex.WaitOne() === Synclock lockObject
someMutex.ReleaseMutex() === End Synclock
someMutex.WaitOne(100, False) === Monitor.TryEnter(lockObject, 100)

   In addition to the equivalences you see above, the Mutex class has two handy shared methods:
   
   Dim someMutexes() As Mutex = {New Mutex, New Mutex, New Mutex}
Sub SomeMethod()
     Dim someInteger As Integer
     someInteger = Mutex.WaitAny(someMutexes)
     Try
          'critical section
     Finally
          someMutexes(someInteger).ReleaseMutex()
     End Try
End Sub

   This will cause the thread to wait until one of the Mutex objects in the array is released, at which point it returns the array index of the Mutex, acquires it, and moves on.
   
   Dim someMutexes() As Mutex = {New Mutex, New Mutex, New Mutex}
Sub SomeMethod()
     Mutex.WaitAll(someMutexes)
     'all Mutex objects are now released
End Sub

   This waits until all Mutex objects in the array are released. I guess this could be good for ensuring that all your threads complete before your program terminates.
   
   Dim someMutex As New Mutex("False", "some name")
   
   Another feature of this class lies in the programmer's ability to assign a name to each Mutex he creates. The spiffy thing about this is that if a Mutex exists anywhere in the system (not just in your program) with that name, it becomes associated with that Mutex.

And I'm spent

References:

• Balena, Francesco. Programming Microsoft Visual Basic .NET (Version 2003). Microsoft Press. 2004.
• MSDN Documentation. <http://msdn.microsoft.com/vbasic/>