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

MultiCore MultiBrain

AMD MultiBrain machine...

Or something like that. It popped up on my radar twice in one day and after the typical Google research it has become apparent this is simply another way of saying MultiCore. This term will not help and will only confuse.

The second time it occurred was on NPR during drive time. I cannot recall the show or episode but I do recall thinking "this is new I need to chase down what AMD is up to.."

The first time was on a Wall Street Journal podcast (I think). So you can see the pattern, venues for popularizing technology will start to use this Multi-Brain when they should say Multi-Core. No doubt some editor felt Multi-Core was too complex. When they were told that details. Hey look the new CPU designs have taken the core functionality of the CPU and duplicated it withinin the CPU multiple times.. the editor trotted out the old 1980s standby CPU=brain and since this gives you multiple CPU capability it must be "MULTI-BRAIN!"

Unfortunately when I hear Multi-Brian I think multiple CPU. And what is worse since no one says brain for cpu anymore, I'm thinking there is something new afoot. AMD must be value adding to the CPU to make it more brainy!

permalink