Event Handlers Are On Separate Threads

You know you are an engineer if you spend an hour arguing over something that can be tested in five minutes.

Below is some code from the Microsoft site that illustrates how to handle FileSystemWatcher events.

I added a few more write lines to report out the thread ids. This clearly shows the event handlers are occurring on separate threads. As an aside, this reinforces the 'bring on the cores' attitude to multicores, since applications tend to be multithreaded even the most simple of applications.


===Code Start===

public static void Main()
{
Watch();
}
public static void Watch()
{
string[] args = System.Environment.GetCommandLineArgs();
// If a directory is not specified, exit program.
if (args.Length != 2)
{
// Display the proper way to call the program.
Console.WriteLine("Usage: FileWatch.exe (directory)");
return;
}
// Create a new FileSystemWatcher and set its properties.
FileSystemWatcher watcher = new FileSystemWatcher();
watcher.Path = args[1];
/* Watch for changes in LastAccess and LastWrite times, and
the renaming of files or directories. */
watcher.NotifyFilter = NotifyFilters.LastAccess NotifyFilters.LastWrite
NotifyFilters.FileName NotifyFilters.DirectoryName;
// Only watch text files.
watcher.Filter = "*.txt";
// Add event handlers.
watcher.Changed += new FileSystemEventHandler(OnChanged);
watcher.Created += new FileSystemEventHandler(OnCreated);
watcher.Deleted += new FileSystemEventHandler(OnDeleted);
watcher.Renamed += new RenamedEventHandler(OnRenamed);
// Begin watching.
watcher.EnableRaisingEvents = true;
//
Console.WriteLine("main thread: " + System.Threading.Thread.CurrentThread.GetHashCode());
// Wait for the user to quit the program.
Console.WriteLine("Press \'q\' to quit the sample.");
while (Console.Read() != 'q') ;
}
// Define the event handlers.
private static void OnChanged(object source, FileSystemEventArgs e)
{
Console.WriteLine("OnChanged thread: " + System.Threading.Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("File: " + e.FullPath + " " + e.ChangeType);
}
private static void OnCreated(object source, FileSystemEventArgs e)
{
Console.WriteLine("OnCreated thread: " + System.Threading.Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("File: " + e.FullPath + " " + e.ChangeType);
}
private static void OnDeleted(object source, FileSystemEventArgs e)
{
Console.WriteLine("OnDeleted thread: " + System.Threading.Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("File: " + e.FullPath + " " + e.ChangeType);
}
private static void OnRenamed(object source, RenamedEventArgs e)
{
Console.WriteLine("OnRenamed thread: " + System.Threading.Thread.CurrentThread.ManagedThreadId);
// Specify what is done when a file is renamed.
Console.WriteLine("File: {0} renamed to {1}", e.OldFullPath, e.FullPath);
}
}

512 Cores by 2017? Can I get more?

Call it the Agarwal corollary to Moore's Law.
Anant Agarwal predicts that the number of cores in the computer will now start doubling every 18 months.
http://www.eetimes.com/showArticle.jhtml;?articleID=206105179

As such we can expect commodity servers to be sporting 512 cores per cpu socket by 2017. This is a future that can come none to soon as far as I am concerned. The only thing that is the least bit troubling is any article (like the one above) related to this MultiCore paradise, always casts it as a looming problem.

I shared this concern for a short while. The reasoning goes something like this, most apps are written as single threaded apps and each core will support only one thread at a time and each thread will use only one core at a time. So when we put that humble single threaded app on the 512 core machine only 1/512 of the processing power will be available to it. All those cores will be wasted!

But something about Agarwal's Corollory broke the spell. (Agarwal's Corollory probably won't stick, I bet it ends up as the "Even More Law") By stating exact numbers one is struck by a sense of "That's it?" Not to be greedy or unappreciative but I will have no trouble making use of 512 threads in an application.

But before even diving off into the specifics for one app let me go look at the process monitor and see what is going on. Okay I have 90 processes running with 970 threads. So it looks like the typical app will use 10 or more threads all by itself.

970 threads on the machine, talk about a plate spinning act. Most people don't realize what the poor OS needs to do here. This is only a dual-core machine so only two threads can be running at a time. But each and every one of those 90 processes need to be responsive like they are the only one running on the machine. To do this the OS is under the covers preemting threads, packaging up their state, then selecting another thread to run, unpackaging it's state, reloading the thread, letting it run for a slice of the cpu and on and on. If the OS is successful it manages to get thru all 970 and back to the first one before anyone notices how sluggish the app is. Think of a plate spinning act were two guys are keeping 970 plates spinning.

Fast forward to the future and 512 cores means the plate spinning act will drop from 485 (970/2) plates to 2 (970/512). All of the context switching burden and performance hit will drop off to zero. So this poor machine could use those 512 cores now. In fact let me launch Visual Studio and SQL Server Management Studio. Now I am up to 97 processes and 1063 threads. Which raises another interesting feature of current software. A single application may result in several processes spinning up as well as multiple threads per process. No doubt large numbers of cores will be consumed by MultiProcess applications. Even if the programmers involved were unable to multithread their applications they could create several processes.

permalink