Multithreading tutorial, part five: Mutex Performance

This is the fifth installment of a multi-part series demonstrating multithreading techniques and performance characteristics in VB.Net. Catch up on the previous installments: Introduction to multithreading, The Application Skeleton, Single Threaded Performance, and SyncLock Performance.

While the last post used SyncLock to mark a “critical section” of code to maintain concurrency, we are now going to take a look at the Mutex class. A word of warning: as the test result show, Mutex is an extremely slow system! You want to be very careful when using Mutex. According to MSDN Magazine (September, 2006), Mutex can take 9801.6 CPU cycles to acquire a lock on a CPU without contention. In comparison to 112 CPU cycles for a Win32 CRITICAL_SECTION (which SyncLock uses), it is easy to see why the decision to use Mutex must be careful weighed.

Here is the code used for this test:

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

  Dim iOriginalMinIOThreads As Integer  twMutexLock = New MutexThreadWorker  Threading.ThreadPool.GetMaxThreads(iOriginalMaxThreads, iOriginalMaxIOThreads)

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

  End If  For IntegerIterationCounter = 1 To Iterations

  Next  While MutexThreadWorker.IntegerCompletedComputations < Iterations  End While

Public Class MutexThreadWorker

  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))    MutexCompletedComputationsLock.WaitOne()

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.

Testing revealed some very unusual performance characteristics. Although a little bit of “spin up” in .Net code is always expected, due to the GAC and what not, initial test runs sometimes took much longer than subsequent tests. Furthermore, tests with high numbers of iterations (such as 1,000,000) seemed to take quite some time to “spin down.” Where the problem is cannot be found without much more in depth investigation. However, it did seem that there is definitely a “break or break” point on an individual system basis for this code, at which point something is going very wrong outside of the code itself. It may quite well be the garbage collector; the code itself had finished running, but the application was still consuming massive amounts of RAM and CPU time long after it reported success. There may be some possible tweaks that can be made to the code itself to assist the garbage collector, but altogether, it seems like Mutex is indeed an incredibly slow system. The speed difference between the Xeon system and the other systems seems to indicate that context switching is also killing performance, since it is running many more threads at once.

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