Multithreading tutorial, part seven: Non-atomic performance

This is the final installment of a seven-part series demonstrating multithreading techniques and performance characteristics in VB.NET. Catch up on the previous installments:

• Part one: Introduction to multithreading
• Part two: The Application Skeleton
• Part three: Single Threaded Performance
• Part four: SyncLock Performance
• Part five: Mutex Performance
• Part six: Monitor Performance

This week’s post on multithreading takes us full circle, back to non-atomic operations. Unlike the first post that tested performance, which performed them in a single thread, this one is multithreaded. Although it is multithreaded, and performs read/writes to shared variables, there is no thread safety whatsoever. As a result, in actual code where the contents shared variables are needed, they cannot be trusted. The variable that holds the number of completed computations is actually trustworthy, because all threads are doing the exact same thing, adding the number 1 to it. If it was doing something less predictable (such as multiplying by the iteration number or adding to a string of characters) the results would be chaotic at best. That is an important distinction to note: while this code is actually functional, in a real program it would probably not work, and definitely not work as expected!

You can download an installer for this program here. The installer will also install the full source code for the project, in a subdirectory of the installation path. Feel free to try it out yourself and tinker with it or just to look at it to get a better understanding of multithreading techniques.

This is the code that launches the threads:

Public Sub NonAtomicMultiThreadComputation(ByVal Iterations As Integer, Optional ByVal ThreadCount As Integer = 0)

  Dim twNonAtomic As NonAtomicThreadWorker

  Dim iOriginalMinIOThreads As Integer  twNonAtomic = New NonAtomicThreadWorker  Threading.ThreadPool.GetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)

  Threading.ThreadPool.GetMinThreads(iOriginalMinThreads, iOriginalMinIOThreads)  If ThreadCount > 0 Then

  End If  For IntegerIterationCounter = 1 To Iterations

  Next  While NonAtomicThreadWorker.IntegerCompletedComputations < Iterations

Public Class NonAtomicThreadWorker

  Public Shared IntegerCompletedComputations As Integer = 0

  Private Shared DoubleStorage As Double  Public Property Storage() As Double

  End Property  Public Property CompletedComputations() As Integer

  End Property  Public Sub ThreadProc(ByVal StateObject As Object)

    Dim ttuComputation As ThreadTestUtilities    ttuComputation = New ThreadTestUtilities    Storage = ttuComputation.Compute(CDbl(StateObject))

TEST 2

In this test, we limit the maximum number of threads to one per logical processor:

TEST 3

This test uses only one thread:

TEST 4

This test uses two concurrent threads:

TEST 5

Here we show four concurrent threads:

TEST 6

This test uses eight concurrent threads:

TEST 7

Finally, this test runs 16 simultaneous threads:

System A: AMD Sempron 3200 (1 logical x64 CPU), 1 GB RAM

System B: AMD Athlon 3200+ (1 logical x64 CPU), 1 GB RAM

System C: Intel Pentium 4 2.8 gHz (1 logical x86 CPU), 1 GB RAM

System D: Two Intel Xeon 3.0 gHz (2 dual core, HyperThreaded CPUs providing 8 logical x64 CPUs), 2 GB RAM

It is extremely important to understand the following information and disclaimers regarding these benchmark figures:

They are not to be taken as absolute numbers. They are taken on real-world systems with real-world OS installations, not clean benchmark systems. They are not to be used as any concrete measure of relative CPU performance; they simply illustrate the different relative performance characteristics of different multithreading techniques on different numbers of logical CPUs, in order to show how different processors can perform differently with different techniques.

As you can see, having no locks occurring results in significant performance gains over the tests that were performed with carious locking mechanisms. However, it is important to understand the ramifications of not using locking. If there is any type of data that needs to be shared amongst threads, locking will have to come into play. Judicial use of locking should prevent the performance hit from being too high. It is also important to note that for many situations, running your computations in a single thread will actually be faster than using multithreading; it all depends on your hardware and what you will actually be doing. As I have said before, “your mileage will vary.” Test, test, and test again to see what techniques work best for your particular application.

We have come to the end of the end of this series. As always, feedback and comments are appreciated.

J.Ja

Daily Tech Insider Newsletter

Stay up to date on the latest in technology with Daily Tech Insider. We bring you news on industry-leading companies, products, and people, as well as highlighted articles, downloads, and top resources. You’ll receive primers on hot tech topics that will help you stay ahead of the game.

Delivered Weekdays

Sign up today