Cleverfoo

For instance in the code below:

using System.Threading;
public class foo {
	public static void Main() {
		new Timer(new TimerCallback(cb),null,200,5000);
		Thread.Sleep(Timeout.Infinite);
	}
	public static void cb(object state) {}
}

the current implementation of Threading.Timer will create a new thread for every new Timer object created. Why is this bad you might ask… well, primarily this is bad because we end up with a bunch of idle threads that do nothing but consume memory just to trigger the TimerCallback delegate at the end of its trigger period. Since each thread requires a chunk of stack space to exist, operating systems can only create a finite amount of threads before running out of memory… this makes threads somewhat of an expensive commodity to be just sitting idle for most of the time.

The patch that I have submitted changes this logic to utilize a single scheduler thread that is in charge of trigger all the timer events registered with its scheduler. The practical implications of this is that n timers can be created at the expense of a single thread.

Enough mambo-jambo, here’s an example of what I described above…

using System.Threading;
using System;

public class foo {
	public static void Main(string[] args) {

		int count = 1000;

		if (args.Length > 0) {
			count = Convert.ToInt32(args[0]);
		}

		Random rad = new Random();
		Console.WriteLine("Starting tests");
		Console.WriteLine("running test for {0} timers", count);

		DateTime start = DateTime.Now;
		for (int i=0;i < count;  i++) {
			new Timer(new TimerCallback(callback),null,rad.Next(5000),rad.Next(5000));
		}
		Console.WriteLine("{0} timers created in {1} msec",count,DateTime.Now.Millisecond - start.Millisecond);
		Thread.Sleep(Timeout.Infinite);

	}

	public static void callback(object state) {
	}
}

The code above just creates n timers (n being args[0]) as quickly as possible and under mono 1.1.13.4 the result is:

[terminal]
[rafael@stan tmp]$ mono timer2.exe 100
Starting tests
running test for 100 timers
100 timers created in 84 msec
[/terminal]

Now, under the single-thread scheduler Timer implementation the result is:

[terminal]
[rafael@stan tmp]$ /devel/bin/mono timer2.exe 100
Starting tests
running test for 100 timers
100 timers created in 66 msec
[/terminal]

So, slightly faster you might think right? Well, being faster is not the main goal of the Timer scheduler, it’s more like a side-effect under these conditions,, so let’s try a better test that really shows its capacity. For instance, changing our test to create a slightly grater number of timers, let’s say 10000 on mono 1.1.13.4:

[terminal]
[rafael@stan tmp]$ mono timer2.exe 10000
Starting tests
running test for 10000 timers
[/terminal]

causes the timer creation loop to never end because my x86 desktop (and pretty much all other systems out there) cannot really create 10k threads. Now, standing on the other side of the ring is our new Timer implementation which…

[terminal]
[rafael@stan tmp]$ /devel/bin/mono timer2.exe 10000
Starting tests
running test for 10000 timers
10000 timers created in 276 msec
[/terminal]

Can handle 10k timers without any issues. However, be warn! CPU consumption does become significant under 10k timers taking anywhere from 8 – 50% on my 1.8Ghz AMD cpu.

Well, I hope this helped you understand how mono’s Threading.Timer class works and how our single thread scheduler hopes to make it even better.