Shafqat Ahmed's .NET Blog

Multi-core CPU Caching: What is volatile?

I must give thanks to Jeffrey Richter for writing his wonderful book called CLR via C# as it cleared up the confusion about volatile keyword that I had.

How does CPU access variables in memory

We all have heard that CPUs have cache memory and having more cache memory at the CPU (L1,L2,L3) makes processing faster so when we buy a computer we try to buy it with a CPU with large cache memory. Why? The reason behind this is that in terms of CPU speed the RAM on motherboard is very slow. The memory that CPU has called cache memory is extremely faster than the normal memory.

So on the first run the CPU accesses the memory address and stores it in the cache. When the variable is accessed for the second time, it is returned from the cache. So all subsequent reads are done from the cache. The same thing happens for write operations as well. When the variable is changed, it is changed into the cache, also subsequent read/writes are done from cache. However the writes are eventually flushed into memory when cache is cleared or filled with other data. One of the intelligent things that the CPU does is when fetching the value of the variable (a few bytes) into the cache, it also fetches the values around it since the next variables to be used should be close by it.

This is fairly fine when you have only one CPU, but most of the PC and Laptops have multiple CPU. Now with the multiple processors this cache access can become problematic. With multi-core CPUs, true threading happens, two machine instructions get executed physically at the same time. Since two processors can have different caches, which are copies of the ram, they can have different values

In x86 and x64 processors (according to Jeffrey’s book) are designed to sync the caches of different processors so we may not see the problem. But the IA64 processor takes the advantage of the fact that each processor has its own cache and does not synchronize rigorously. So different threads executing may have put in different values in the cache.

Please note that one CPU may write to the its own cache, which will eventually be transferred to RAM, the other CPU may have read from the RAM which contained old value since the first CPU has not updated the value yet. See below (click on image for larger view)

So this creates an obvious concurrency problem. That is where the volatile keyword comes in. If you declare a field volatile it is always read from memory and written into memory immediately. However it must be noted that all interlocked operation (again thank to Jeffrey) like lock, Monitor, Mutex, Semaphore etc synchronizes the caches. So this volatile keyword is not needed for those.

But volatile variables are slower. It would have been great if there was a write volatile only variable.

CLR Fun Stuff: How is my C# code converted into machine instructions?

As we all know that our .NET code (C#, VB.NET etc) are converted into MSIL instructions which in turn are put into the assemblies. MSIL is a high level language, not as low as machine instructions, so it needs to converted into machine specific binary code or needs to be interpreted somehow. Since interpretation would make the execution significantly slower, the code is converted into machine code on access. This is done via a procedure called Just in time compilation (JIT). Just in time is a management concept that was introduced by Ford Motors into production environment. This is a process where inventory was brought on time just before they were needed, and this saved the warehousing or storing costs.

How does JIT compilation happen?

In programming JIT works like this. Since the executable or the library is made of MSIL (bytecode or any other intermediate form) instruction it needs to be compiled into machine code, but if we convert all of the code into machine format then it will take time. For example if we have an application has 50 functions and we use 3 of them regularly, then if each time when we load the program and compile all the 50 functions then it would be a waste of time and would take a long time to load. What JIT does is to convert the function's MSIL into machine code just before executing the function. See the figure to see how a code is compiled via JIT. Once a code has been transformed into native machine code it stays in memory and next calls to function are pointed to that same memory so that the conversion to machine code is done only once in the lifetime of an executable.

A little deeper look: The secret undocumented CLR function that does it all

When a .NET application loads then it loads the MsCorEE.dll which loads the correct version of the MsCorWks.dll (the version of .NET we are running) which contains all core functions of the .NET runtime. For more detail on loading see the web, one good resource can be this post NET Foundations - .NET execution model. There is this function called _CorExeMain which actually loads the CLR and all the types that are required into memory. There is a memory table for types and there are tables for functions and properties of each types.

Lets say we have a class that looks like this

class TestClass
{
   static void ConsoleAdd ( int value1, int value2)
  {
     Console.WriteLine ( value1 + value2);
  }
}

Now a careful look would tell us that only 2 types are used here TestClass and Console. If we call the TestClass.ConsoleAdd function from the main method this is how the memory looks like before the function is called.

Before the call both the ConsoleAdd and WriteLine and other functions are pointing to the secret JITC function. This is how each time the JITC functions compiles the code into native code and replaces the function pointer in the function table for the type.

            

Now lets look at the memory after it has been JITed.

Last words

So now we know how our C# code is compiled in to native code. It may be hard to believe that at certain times JITed code runs faster than the native compiled code. When a code is JIT compiled it takes the advantage of the exact CPU instructions present the the machine but the native compiled code compiles into more generic class of machine instructions. We will read about advantage and disadvantages of JIT another day.

New* .NET 3.5 Feature: AddIn Framework Resources (Part 2 of 2)

I was starting to write a 3 part series on the new AddIn Framework in .NET 3.5. However I came across some resources which makes me end this series and rather point to those posts and articles since they have already described it so nicely. Here are the articles and blog posts

MSDN Magazine : CLR Inside Out : .NET Application Extensibility by Jack Gudenkauf and Jesse Kaplan

This MSDN article introduces the concept of System.Addin namespace concepts and how it is structured. This actually provides

MSDN Magazine : CLR Inside Out : .NET Application Extensibility Part 2  by Jack Gudenkauf and Jesse Kaplan

This is the second article of the extensibility series that describes the pipeline architecture that was used, each of the components and how it is implemented. A must read anyone who wants to implement the addin model.

How To: Build an Add-In using System.AddIn by Guy Burstein

This is the practical hands on example with code examples and many screenshots. A tutorial cannot get any better than this. A must visit to the addin implementer. Make sure you visit this article, this is written by a tech evangellist at Microsoft.

CLR Add-In Team Blog

This is the .NET based blog of the people who made the framework and contains many inside information you may not find in the documentation. It is a nice place to visit every once in a while.

Everything you need to know to get started with System.AddIn by James Green

This is another good start point for addin examples with visual diagrams.

New* .NET 3.5 Feature: AddIn Framework ( Part 1 of 2 )

2ne of the new items that were included in the .NET 3.5 framework is a built in way to add extensibility to your application using add-ins, also known as plug-in. Many of us have already added extensibility in our own application using interfaces. However this framework comes with a few built in features for addin lifetime management, security isolations etc.

Sandbox Isolation

If we want to add termination features to an addin we would need to load it to to different appdomain since we may want to unload it or reload it when any error happens. Also when the addin runs in a separate domain space it is less likely to corrupt any part of the application.

Please also note that when an addin is unloaded, the unloading causes the other assemblies to be unloaded as well on which the addin is dependent upon. This happens because the AppDomain is unloaded.

Discovery

The new framework also supports discovery of addins within a folder. Also you can also search for a certain addin. According to the documentation each addin has its own folder and its own set of assemblies.

Security

The security of the sandboxed addin can be created when we create the application domain for the addin to run on or we can even use the policy level security to control the addin behavior.

Versioning

Versioning is provided via contract isolation, both the addin host and the addin itself can version independently of each other. A concept of adapter assembly is present for both the add in and the host so that the implementation can change independently.

Termination

Due to running the addin in different AppDomain boundary termination of the AppDomain automatically clears memory and all other resources. However if we needed to do this manually then we would have to find the application domain that hosts the assembly and unload it. The framework provides a nifty class to unload the addin and its AppDomain

AddInController.GetAddInController(addin).Shutdown();

Next

Related Post:

Dll heaven: Executing multiple versions of the same assembly

Dll heaven: Executing multiple versions of the same assembly

Everyone wants their application to be backward compatible and if the application is based on a plug-in based architecture then such a feature can be a nice addition. When can such a feature be useful? Suppose we have a plug-in subsystem which we have upgraded to newer plug-in system and we want to support older systems.

So if we want to load 2 different versions of a same assembly what do we need to do?First, each version needs to be loaded into 2 different AppDomains.

Why ?

Because when an assembly is loaded it cannot be unloaded so if we have 2 different assemblies once a type has been loaded from one of them, it will be reused each time we want to instantiate a type. But an assembly loaded into an AppDomain can be unloaded by unloading the AppDomain itself. I am going to demonstrate how to load 2 versions of the same assembly into same executable and run them simultaneously.

Example Step 1: In order to make it simple and avoid the reflection trouble I am going to create an interface and put it into a dll and reference the interface to the concrete dll. So here is code for the interface class in a simple dll that will be used to invoke methods.

namespace InterfaceLib
{
    public interface IExecute
    {
        string Execute();
    }
}

Example Step 2:I will build this into a single dll and then reference it to the interface. We need to make the class inherit from MarshalByRefObject since we want to communicate across AppDomains.

namespace AssemblyVersionTest
{
    public class SimpleClass : MarshalByRefObject, 
        InterfaceLib.IExecute
    {
        public string Execute()
        {
            return "This is executed from version 1";
        }
    }
}

So we have a class that is referenced from MarshalByRefObject and implement our interface. Lets compile this dll and after doing so ... take the dll and rename it to AssemblyVersionTest1.dll

Lets now change this line

return "This is executed from version 1;

to

return "This is executed from version 2";

Then again compile the dll and rename it to AssemblyVersionTest2dll

Example Step 3:Now we come to our third application, the console executable. Lets put the 2 versions of the dll to the bin path of the console executable and use the following code

// Create an app domain
AppDomain appDomain1 = AppDomain.CreateDomain("Version1");
// Instantiate the object from the app doamin and the first version file
object obj= appDomain1.CreateInstanceFromAndUnwrap(
    AppDomain.CurrentDomain.BaseDirectory + "\\AssemblyVersionTest1.dll", 
    "AssemblyVersionTest.SimpleClass");
IExecute iex = (IExecute)obj;
// Instantiate the object from the app doamin and the second version file

AppDomain appDomain2 = AppDomain.CreateDomain("Version2");
object obj2 = appDomain2.CreateInstanceFromAndUnwrap(
    AppDomain.CurrentDomain.BaseDirectory + "\\AssemblyVersionTest2.dll", 
    "AssemblyVersionTest.SimpleClass");
IExecute iex2 = (IExecute)obj2;

Console.WriteLine(iex.Execute());
Console.WriteLine(iex2.Execute());

Now observe that we have had renamed the different versions of the dlls and loaded them explicitly. The output of the above code should be ...

This is executed from version 1
This is executed from version 2

Now we can see that the domains have loaded 2 different versions of the same class in the same executable and executed them.

WeakReference: GC knows the Best

When I first read about weak references in .NET more than 5 years ago back my first thought was to use it for Caching. The concept was already present in Java before .NET since Java had garbage collection before. Still today I don't see many developers using this awesome class.

What is a Weak Reference?

We all know that garbage collectors start cleaning memory for objects that do not have any reference. A weak reference is a way to have some pointer to an object that does have any reference (strong reference). When we need to access a weak referenced object we can just check if the object is alive and then access it if the object is alive at all. Since .NET is a garbage collection based runtime environment, like all GC based runtimes it does not immediately clean up the memory allocated for the instantiated objects. 

Why should we use it?

Not having a strong reference to the object but at the same time having a pointer to the object enables this class to be well suited for caching. 

When to use Weak Reference?

Since GC executes when there is memory pressure and cleans objects that are in memory. At the same time if memory and processing is expensive for your application then you can reduce pressure on memory and processing at the same time. Let try an example ... 

Lets assume that we have an object that contains is 500KB of data and when we fetch it it quite expensive to get because of the IO operation required to fetch it from database and we need to validate it with some rule. And at the same time we have to have 1000 of these objects instantiated with different sets of data. 

We can use traditional cache but that would use too much memory or we can fetch the instance each time for database. Both solutions have its own flaw. The first uses too much memory and the second one uses too much processing. This would be the best solution to use weak reference 

There are 2 cases possible when we need to access any instance of the object in question 

1. It may not be garbage collected: So the object is still in memory and we can associate a strong reference to it and use it. This saves performance but uses memory without any extra pressure since GC takes the best decision when to collect. 

2. It may have been collected and does not exist anymore: In this scenario we will fetch the object again. So we would be using processing power. The memory pressure was high and GC decided to collect and our onject went with that so we need to fetch the object again. Here again we are letting GC decide when the memory pressure is enough that we would to a high processing action. 

So the basic belief behind WeakRefernce is that "GC knows best". It will clean up memory when needed and we puny humans should respect its decision on memory management. 

How to use WeakReferences?

All you need to do is create a WeakReference class with the object in question passed into the constructor. Keep a storng refence to the weak reference object. When need later then check if obect is alive by checking 'IsAlive' property and then use it. The code sample below shows the lifetime of an object when using a weak reference ...

// Create the object
Book book = new Book("My first book", "Me");
// Set weak reference
WeakReference wr = new WeakReference(book);
// Remove any reference to the book by making it null
book = null;
if (wr.IsAlive)
{
    Console.WriteLine("Book is alive");\
    Book book2 = wr.Target as Book;
    Console.WriteLine(book2.Title);
    book2 = null;
}
else
    Console.WriteLine("Book is dead");
            
// Lets see what happens after GC
GC.Collect();

// Should not be alive
if (wr.IsAlive)
    Console.WriteLine("Book is alive");
else
    Console.WriteLine("Book is dead");

The output should be

Book is alive
My first book
Book is dead

So folks ... that all about weak references.

Controlling Windows Firewall using C# via COM Interop

Windows firewall is the built in firewall that ships with Windows XP and Windows Vista. This firewall can be controlled from any .NET language via COM interop. The windows firewall UI is a little clumsy to work with so anyone can make his own frontend using any .NET based language.

Setting up

Start by adding a reference to the COM dll that provides the functionality to control the windows firewall. The filename is hnetcfg.dll which can be found at the system32 folder inside windows. So add the file to your C# project.

File location: \Windows\System32\hnetcfg.dll
Then add these using statements to import the COM Objects

using NATUPNPLib;
using NETCONLib;
using NetFwTypeLib;

Obtaining a reference to the firewall manager

The first step toward controlling the windows firewall is to obtain a reference to the firewall manager class. For this we will use the CLSID of the class which is

   {304CE942-6E39-40D8-943A-B913C40C9CD4}

So our code looks like this

private const string CLSID_FIREWALL_MANAGER = 
      "{304CE942-6E39-40D8-943A-B913C40C9CD4}";
private static NetFwTypeLib.INetFwMgr GetFirewallManager()
{
    Type objectType = Type.GetTypeFromCLSID(
          new Guid(CLSID_FIREWALL_MANAGER));
    return Activator.CreateInstance(objectType) 
          as NetFwTypeLib.INetFwMgr;
}

The above code shows how to get a reference to the firewall manager

Check if the firewall is turned on

If the firewall is not turned we should look into the current profile and find out then turn it on.

INetFwMgr manager = GetFirewallManager();
bool isFirewallEnabled = 
    manager.LocalPolicy.CurrentProfile.FirewallEnabled;
if (isFirewallEnabled==false)
    manager.LocalPolicy.CurrentProfile.FirewallEnabled=true;

Give full trust to your executable

If we want to authorize some application with full trust then we need to create a FirewallAuthorizedApplication (INetFwAuthorizedApplication) object and add it to the authorized application list.

// ProgID for the AuthorizedApplication object
private const string PROGID_AUTHORIZED_APPLICATION = 
    "HNetCfg.FwAuthorizedApplication";
public bool AuthorizeApplication(string title, string applicationPath, 
    NET_FW_SCOPE_ scope, NET_FW_IP_VERSION_ ipVersion )
{    
  // Create the type from prog id
  Type type = Type.GetTypeFromProgID(PROGID_AUTHORIZED_APPLICATION);
  INetFwAuthorizedApplication auth = Activator.CreateInstance(type) 
      as INetFwAuthorizedApplication;
  auth.Name  = title;
  auth.ProcessImageFileName = applicationPath;
  auth.Scope = scope;
  auth.IpVersion = ipVersion;
  auth.Enabled = true;

  INetFwMgr manager = GetFirewallManager();
  try
  {
    manager.LocalPolicy.CurrentProfile.AuthorizedApplications.Add(auth);
  }
  catch (Exception ex)
  {
    return false;
  }
  return true;
}

The above code is for a function that adds an authorized application. Let see the use by authorizing notepad full internet access!

AuthorizeApplication ("Notepad", @"C:\Windows\Notepad.exe", 
                NET_FW_SCOPE_.NET_FW_SCOPE_ALL,
                NET_FW_IP_VERSION_.NET_FW_IP_VERSION_ANY)

Walla! Now notepad has internet access.

Opening a Port Globally

Sometimes we may want to open a port for any application no matter what. Windows Firewall can be instructed to open a port globally for all applications by adding a port to the globally open ports list. Let try to write a function that opens up a port globally ...

private const string PROGID_OPEN_PORT = "HNetCfg.FWOpenPort";

public bool GloballyOpenPort(string title, int portNo, 
    NET_FW_SCOPE_ scope, NET_FW_IP_PROTOCOL_ protocol, 
    NET_FW_IP_VERSION_ ipVersion)
{
  Type type = Type.GetTypeFromProgID(PROGID_OPEN_PORT);
  INetFwOpenPort port = Activator.CreateInstance(type) 
      as INetFwOpenPort;
  port.Name = title;
  port.Port = portNo;
  port.Scope = scope;
  port.Protocol = protocol;
  port.IpVersion = ipVersion;
  INetFwMgr manager = GetFirewallManagerCached();
  try
  {
    manager.LocalPolicy.CurrentProfile.GloballyOpenPorts.Add(port);
  }
  catch (Exception ex)
  {
    return false;
  }
  return true
}

Going further

Since we have demonstrated how to access the windows firewall manager and control its various aspects, now anyone can explore the Windows Fireall API and do a lot more that presented in this post. I would like to point to several MSDN references for further read.

MSDN Windows Firewall Reference
Loads of VBScript samples to do various things, you can translate the code to C#

Since windows firewall can be controlled via COM, any application running in your system can enable/disable or modify the firewall settings. I would suggest to use a third party firewall. For real security geek I would recommend Outpost Firewall ( I use the Outpost Security Suite) as the paid firewall and Comodo Personal Firewall as the best free firewall. Both these firewalls are way superior to other available firewalls.

Web 2.0 Bubble

Got this video from someone ... the perfect description of web 2.0 phenomena. I love this ... this guy has taken words out of my mouth and put in his video.

Independent Thought

The certificate of 925-201b hold questions about principles of network security and fortigate configurations. On the other hand, 70-624 certifications belong to deploying and maintaining vista client and office system 2007. E22-128 training question belongs to EMC technology fundamentals and is a very essential course. Whereas, E20-570 also belongs to the EMC technology but hold more advance questions. HH0-110 certification belongs to the Hitachi data storage foundation and person need 65% marks in order to pass the exam. EC0-350 holds all the questions related to ECCOUNCIL Ethical Hacking and Countermeasures.