One curious thing about C# is that it can use two different operators to calculate an and expression: the & operator and the && operator. The difference between both is that the first one (&) can be used both with integer types and boolean types. When used with integer types it will perform a bitwise comparison between the two, and when used with boolean values it will use the logical and operation between the two boolean values, evaluating all the parts of the expression. This means that using a code like this one:

if (someObject != null & someObject.SomeProperty == someValue)

will throw a runtime error if someObject is null, because it will try to obtain the SomeProperty value.

However, the && operator is only available to boolean expressions, and it uses lazy evaluation, this is, if the first condition evaluated is false, it will calculate false without evaluating the rest of the expression, because an and is only true if all the expressions are true.

Conclusion, be sure to always use &amp& when evaluating boolean values if you want to avoid run time surprises .

Since the implementation alone would be rather simple for a post, I’ll show you how to implement Unit Testing with the class using Nunit. Although this is a rather simple class to test I think it will show the basic concepts behind unit testing.

First of all let’s begin with the interface of the class. We will call it LinkedListQueue<T>. We basically need the typical operations of a queue.

The interface (without the implementation) is going to be something similar to this:

using System;
public class LinkedListQueue
{
 
    #region LinkedListQueue Members
 
    public T Dequeue()
    {
        throw new System.NotImplementedException();
    }
 
    public void Enqueue(T item)
    {
        throw new System.NotImplementedException();
    }
 
    public T Peek()
    {
        throw new System.NotImplementedException();
    }
 
    public void Clear()
    {
        throw new System.NotImplementedException();
    }
 
    public int Count
    {
        get { throw new System.NotImplementedException(); }
    }
 
    #endregion
}

The thing about unit testing is to first write the different tests so we know what we want to test and then we have to write the code so the tests are passed. Following this convention, now is the time to write some tests using Nunit. To do so, we have to create a new project of type Class Library in Visual Studio (we could have the tests on the same code but it’s better to have it separately so we don’t bloat the real production code). For more information about how to install and set up Nunit I suggest you visit the site for more information. I called the project LinkedListQueueTest

Once we have the code, we can start writing tests in a special class which will have this modifier:

[TestFixture]
public class LinkedListQueueTest
{}

Inside this class we have to write one method for each test we want to perform. It’s usually a good practice to have one test per method on the class you’re testing. In our case, we will begin testing the Enqueue method. To mark a method as a test, we have to add a modifier to it like this:

[Test]
public void Dequeue()
{}

And in the body of the method, we have to perform the test we need. Usually the tests have a structure: creating an object on which to test, executing the method, and confirm that the result is the same as we expected. Let’s do a simple code for our test:

[Test]
public void Dequeue()
{
    LinkedListQueue queue = new LinkedListQueue();
    //We enqueue some items to test
    queue.Enqueue(1);
    queue.Enqueue(2);
    queue.Enqueue(3);
    queue.Enqueue(4);
    queue.Enqueue(5);
    //For each number enqueued we check that is removed properly and in the
    //queue order (FIFO)
    Assert.AreEqual(queue.Dequeue(), 1);
    Assert.AreEqual(queue.Count, 4);
    Assert.AreEqual(queue.Dequeue(), 2);
    Assert.AreEqual(queue.Count, 3);
    Assert.AreEqual(queue.Dequeue(), 3);
    Assert.AreEqual(queue.Count, 2);
    Assert.AreEqual(queue.Dequeue(), 4);
    Assert.AreEqual(queue.Count, 1);
    Assert.AreEqual(queue.Dequeue(), 5);
    Assert.AreEqual(queue.Count, 0);
    Assert.Throws(
        delegate
        {
            queue.Dequeue();
        }
    );
}

I suggest you read the Nunit documentation to see the different assertions you have available.

Now that we wrote our first test, we should start thinking and writing the rest of the tests. To simplify the post, here’s a full class showing some tests that you may have wanted to perform:

using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;
 
namespace ThinkInGeek.Collections.Generic.Testing
{
    [TestFixture]
    public class LinkedListQueueTest
    {
        [Test]
        public void Dequeue()
        {
            LinkedListQueue queue = new LinkedListQueue();
            //We enqueue some items to test
            queue.Enqueue(1);
            queue.Enqueue(2);
            queue.Enqueue(3);
            queue.Enqueue(4);
            queue.Enqueue(5);
            //For each number enqueued we check that is removed properly and in the
            //queue order (FIFO)
            Assert.AreEqual(queue.Dequeue(), 1);
            Assert.AreEqual(queue.Count, 4);
            Assert.AreEqual(queue.Dequeue(), 2);
            Assert.AreEqual(queue.Count, 3);
            Assert.AreEqual(queue.Dequeue(), 3);
            Assert.AreEqual(queue.Count, 2);
            Assert.AreEqual(queue.Dequeue(), 4);
            Assert.AreEqual(queue.Count, 1);
            Assert.AreEqual(queue.Dequeue(), 5);
            Assert.AreEqual(queue.Count, 0);
            Assert.Throws(
                delegate
                {
                    queue.Dequeue();
                }
            );
        }
 
        [Test]
        public void Enqueue()
        {
            LinkedListQueue queue = new LinkedListQueue();
            //We enqueue some items to test and check that the items are inserted correctly
            queue.Enqueue(1);
            Assert.AreEqual(queue.Count, 1);
            queue.Enqueue(2);
            Assert.AreEqual(queue.Count, 2);
            queue.Enqueue(3);
            Assert.AreEqual(queue.Count, 3);
            queue.Enqueue(4);
            Assert.AreEqual(queue.Count, 4);
            queue.Enqueue(5);
            Assert.AreEqual(queue.Count, 5);
        }
 
        [Test]
        public void Peek()
        {
            LinkedListQueue queue = new LinkedListQueue();
            //We enqueue some items to test
            queue.Enqueue(1);
            queue.Enqueue(2);
            queue.Enqueue(3);
            queue.Enqueue(4);
            queue.Enqueue(5);
            //We check that after a peeking we have the correct value but the item
            //is not deleted
            Assert.AreEqual(queue.Peek(), 1);
            Assert.AreEqual(queue.Count, 5);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 2);
            Assert.AreEqual(queue.Count, 4);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 3);
            Assert.AreEqual(queue.Count, 3);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 4);
            Assert.AreEqual(queue.Count, 2);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 5);
            Assert.AreEqual(queue.Count, 1);
            queue.Dequeue();
            Assert.Throws(
                delegate
                {
                    queue.Peek();
                }
            );
        }
 
        [Test]
        public void Clear()
        {
            LinkedListQueue queue = new LinkedListQueue();
            queue.Enqueue(1);
            queue.Enqueue(2);
            queue.Enqueue(3);
            queue.Enqueue(4);
            queue.Enqueue(5);
            queue.Clear();
            Assert.AreEqual(queue.Count, 0);
        }
    }
}

To see how our test behave, we have to open the resulting LinkedListQueueTest.dll in the Nunit tester program. As we have written no real code on the queue class, it’s obvious that our tests will fail. So let’s get our hands dirty and start programming our queue.

I will not go into the details because a linked list based queue is really easy to implement, so here’s the final code of the class:

using System;
 
namespace ThinkInGeek.Collections.Generic
{
    public class LinkedListQueue
    {
        #region Node inner class
 
        public class Node
        {
            public K Element { get; set; }
            public Node NextElement { get; set; }
        }
 
        #endregion
 
        #region Private members
 
        private int m_count = 0;
        private Node m_head = null;
        private Node m_tail = null;
 
        #endregion
 
        public T Dequeue()
        {
            if (m_head == null)
            {
                throw new InvalidOperationException();
            }
            //We have to return the item on the head and update the new head
            T currentItem = m_head.Element;
            m_head = m_head.NextElement;
            m_count--;
            return currentItem;
        }
 
        public void Enqueue(T item)
        {
            //We need to add the item and update the tail
            Node newNode = new Node();
            newNode.Element = item;
            if (m_tail != null)
            {
                m_tail.NextElement = newNode;
            }
            m_tail = newNode;
            if (m_head == null)
            {
                m_head = newNode;
            }
            m_count++;
        }
 
        public T Peek()
        {
            if (m_head == null)
            {
                throw new InvalidOperationException();
            }
            return m_head.Element;
        }
 
        public void Clear()
        {
            m_head = null;
            m_tail = null;
            m_count = 0;
        }
 
        public int Count
        {
            get { return m_count; }
        }
    }
}

The advantage of unit testing is that now the testing is going to be done automatically. The only thing we have to do is open the testing dll file into Nunit and see how’s the outcome. As we’re really good programmers, using the code I showed you, all the tests will pass

Unit Testing results window

This is a really simple example of how things should be done with unit testing using C# and Nunit, but I hope it can get you started and you can grasp the philosophy of it. For more information I really recommend reading the book Pragmatic Unit Testing in C# with NUnit.

For those who don’t know jQuery, it’s an opensource Javascript framework that is going to be embedded on future versions of Visual Studio. It’s a very good framework because of its simplicity and its extensibility, having lots of plugins. One of those plugins is the blockUI plugin, which allows you to block and unlock any part of the DOM at will.

Let’s try this with a simple example. Imagine you have an UpdatePanel with various buttons, and you want that when a user clicks on any of it, all the interactive controls of the UpdatePanel become disabled until the asynchronous response has come back and the html has been updated. To do this, we need to know when the UpdatePanel is being updated. The best way to do this is to listen to an event of the PageRequestManager object of our web page. The event is called beginRequest and the way we can attach to it is as follows.

Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(BeginRequestHandler);

This will get the instance of the PageRequestManager object and add a listener to the event, pointed at the javascript function called BeginRequestHandler.

The next step is to actually write this function. One option here would be to manually disable all the controls inside the UpdatePanel that can trigger a postback, but that would be very tedious. Instead, I propose you a way to directly disable all the UpdatePanel. We can do so by using the blockUI plugin from jQuery.
The method will look like this.

function BeginRequestHandler(sender, args) {
    $('#').block();
}

This might need a bit of explanation. In jQuery, when using $(‘#element’) we select the element of the DOM that has the id ‘element’. This returns a jQuery object upon which we can execute a series of commands (more on jQuery selectors on the jQuery website). Of those operations we can perform, there’s one that is provided with the blockUI plugin, and it’s called block(). This operation will simply block the DOM element that the jQuery selector has selected. With this simple line of code, then, we can disable an entire UpdatePanel. Since the UpdatePanel will be redrawn when the asynchronous postback comes back, it will be redrawn enabled again, so we don’t have to worry about enabling it again.

I suggest you visit the documentation of the blockUI plugin for more information and blocking options. In this example we simply disable the controls, but using some nice CSS you could use messages and html elements to notice the user that something is going to happen, like a nice Loading meassage or something similar.

 
    <script src="jquery.js" type="text/javascript"><!--mce:0--></script>
    <script src="jquery.blockUI.js" type="text/javascript"><!--mce:1--></script>
 
<form id="form1">
<div>
 
    <script type="text/javascript"><!--mce:2--></script></div>
</form>

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Threading;
 
namespace UpdatePanelBlockExample
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            Thread.Sleep(3000);
            Label1.Text = DateTime.Now.ToLongDateString();
        }
 
        protected void Button1_Click(object sender, EventArgs e)
        {
            Thread.Sleep(3000);
            Label1.Text = DateTime.Now.ToShortDateString();
        }
    }
}

Python and Ruby lovers will see now that they can use all the library and features of the .NET platform programming in their favorite scripting language. Since both of them are object oriented, you can now write fully fledged apps using either of them.

However, there’s another interesting application for IronPython and IronRuby: adding scripting support for your existing .NET applications. This can be a very useful and powerful way to extend your applications and give the user freedom to program their own mini programs, scripts or whatever in your applications. It could be good for defining rules, assigning and calculating values, etc.

I’ll provide a simple class you can use to add scripting to your application. I’ll use IronPython in this example.

First of all, you have to download IronPython and install it, and add the references to the assemblies on your project references.

The usual way to proceed in those cases is to provide the user of some local variables you give them access to, execute the script, and then recover the values of those or new variables. To do so, You can use a class similar to this one:

using System;
using System.Collections.Generic;
using System.Text;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
using Microsoft.Scripting;
 
namespace Scripting
{
	internal class PythonEngine
	{
        ScriptEngine m_engine;
        ExceptionOperations m_exceptionOperations;
        SortedDictionary<string, object> m_inputVariables;
        string m_script;
 
        internal PythonEngine()
        {
            m_engine = Python.CreateEngine();
            m_exceptionOperations = m_engine.GetService<ExceptionOperations>();
        }
 
        internal SortedDictionary<string, object> ScriptVariables
        {
            set { m_inputVariables = value; }
        }
 
        internal string Script
        {
            set { m_script = value; }
        }
 
        internal ExceptionOperations ExceptionOperations
        {
            get { return m_exceptionOperations; }
        }
 
        internal SortedDictionary<string, object> Execute()
        {
            //Create structures
            SourceCodeKind sc = SourceCodeKind.Statements;
            ScriptSource source = m_engine.CreateScriptSourceFromString(m_script, sc);
            ScriptScope scope = m_engine.CreateScope();
            //Fill input variables
            foreach (KeyValuePair<string, object> variable in m_inputVariables)
            {
                scope.SetVariable(variable.Key, variable.Value);
            }
            SortedDictionary<string, object> outputVariables = new SortedDictionary<string, object>();
            //Execute the script
            try
            {
                source.Execute(scope);
                //Recover variables
                foreach (string variable in scope.GetVariableNames())
                {
                    outputVariables.Add(variable, scope.GetVariable(variable));
                }
            }
            catch (Exception e)
            {
                string error = m_exceptionOperations.FormatException(e);
                //Do something with the pretty printed error
                throw;
            }
            return outputVariables;
        }
	}
}

Usage of this class is pretty simple. You have to provide the object the script you want to execute and the input variables the script will have available as local variables. Once this is done, you have to call the Execute method, and this method will either return the output variables of the execution of the resulting script, or throw an exception.

Cropped ComboBox

This is annoying because users cannot read properly the information. To solve that problem, all we have to do is derive the ComboBox class and override the DropDown event as follows:

public class ComboBoxEx : ComboBox
{
	public ComboBoxEx()
		: base()
	{
		DropDown += new EventHandler(event_DropDown);
	}
 
	void event_DropDown(object sender, EventArgs e)
	{
		try
		{
			ComboBox comboBox = (ComboBox)sender; // Catch the combo firing this event
			int width = comboBox.Width; // Current width for ComboBox
			Graphics g = comboBox.CreateGraphics(); // Get graphics for ComboBox
			Font font = comboBox.Font; // Doesn't change original font
 
			//checks if a scrollbar will be displayed.
			int vertScrollBarWidth;
			if (comboBox.Items.Count > comboBox.MaxDropDownItems)
			}
				//If yes, then get its width to adjust the size of the drop down list.
				vertScrollBarWidth = SystemInformation.VerticalScrollBarWidth;
			}
			else
			{
				//Otherwise set to 0
				vertScrollBarWidth = 0;
			}
			//Loop through list items and check size of each items.
			//set the width of the drop down list to the width of the largest item.
			int newWidth;
			foreach (string s in comboBox.Items)
			{
				if (s != null)
				{
					newWidth = (int)g.MeasureString(s.Trim(), font).Width + vertScrollBarWidth;
					if (width < newWidth)
						width = newWidth;
				}
			}
			// Finally, adjust the new width
			comboBox.DropDownWidth = width;
		}
		catch {  }
	}   
}

The following picture shows the results of using the above control instead of the default one:

Non Cropped ComboBox

Imagine you want to list all the files on C: on the SQL Server Windows host: you could write a T-SQL statement like this one:

EXECUTE master..xp_cmdshell 'dir c:'

This stored procedure, however, is a very dangerous one, as it would allow to execute harmful code. This is the reason why it’s disabled by default. Even when enabled, only users on the sysadmin role can use it.

If you ever need some users the ability to run only some specific commands with xp_cmdshell, you can use the method I’ll explain below, making use of the EXECUTE AS modifier of the stored procedure definitions in T-SQL.

The proposed solution involves five steps:

• Enabling the xp_cmdshell extended procedure.
• Adding a procedure on the database with the EXECUTE AS modifier as an administrator, controlling which commands are allowed to be executed.
• Modifying or creating the xp_cmdshell_proxy_account, associating it to a user with sysadmin privileges.
• Giving the user(s) you want the EXECUTE privileges to the procedure.
• Grant the proxy account user the privilege to log on as a batch in the Windows server.

The execution of xp_cmdshell must be enabled on the SQL Server. This can be done through the SQL Surface Area Configuration utility or by code. Refer to Figure below on how to activate xp_cmdshell through the SQL Surface Area Configuration.

SQL Surface Area

To enable xp_cmdshell using SQL code, use the sentences below:

EXEC master.dbo.sp_configure 'show advanced options', 1
RECONFIGURE
EXEC master.dbo.sp_configure 'xp_cmdshell', 1
RECONFIGURE

This will allow users of the sysadmin role, and no one else, to execute xp_cmdshell.

Now we have to create a special stored procedure that will control the actions used as parameters to xp_cmdshell. This will allow the administrators of the database to have control over which commands they allow to be executed on their servers. The most important part of this procedure is the EXECUTE AS OWNER modifier. By using this modifier, everyone that runs that procedure will be able to run it as if it was the owner of the database, thus having execute permissions to xp_cmdshell (we’re assuming the procedure will be created in the master schema. By granting execute permissions on that procedure, you will allow specific users an indirect way to call the xp_cmdshell.

Using this method, only the users of the sysadmin role will be able to execute xp_cmdshell, and only the users you grant EXECUTE permissions on the stored procedure will be able to execute the specific commands that you allow.

To insert the store procedure, log in as a sysadmin on the database and create it with the EXECUTE AS OWNER modifier on it.

For the above procedure to work on non sysadmin accounts there is another step that has to be done. By default, even if you have permissions on the store procedure, you won’t be able to execute it if you’re not on the sysadmin role. This is because those users need a proxy account that is used as the account in which the xp_cmdshell is executed.

So, for this procedure to work, you must create or modify the xp_cmdshell_proxy_account with a user within the sysadmin role. To setup this account, proceed with the code below:

EXEC sp_xp_cmdshell_proxy_account 'MyDomain\MyUserName', 'myDomainPassword'

If the above code does not work, try this one:

CREATE credential ##xp_cmdshell_proxy_account## with identity = 'Domain\DomainUser', secret =  password'

After the procedure and the proxy account have been set, the users we want to be able to execute the procedure must be granted EXECUTE permission on it. To do so, execute this statement for every user you want to grant permissions:

GRANT EXECUTE ON Tango_xp_cmdshell TO <username>;
GO

To grant this permission, use the Local Security Settings on the Administrative Tools interface of the Windows Control Panel. Once there locate the property shown on the screenshot and add the user you gave permissions to the user list.

Local Security Policy

Note that enabling the xp_cmdshell command may still have some security implications, so try to avoid it when possible.

So, what’s the matter with StringBuilders in C#?

It seems the same thing happens with Strings, C# and Java. Here is a copy paste from the MSDN web page about the StringBuilder usage:

The String object is immutable. Every time you use one of the methods in the System.String class, you create a new string object in memory, which requires a new allocation of space for that new object. In situations where you need to perform repeated modifications to a string, the overhead associated with creating a new String object can be costly. The System.Text.StringBuilder class can be used when you want to modify a string without creating a new object. For example, using the StringBuilder class can boost performance when concatenating many strings together in a loop.

So I decided to run some tests to see how much it was worth to change my code to use the StringBuilder class, because I use the string ‘+’ operator a lot in my program, and the results are simply amazing. Here you can find a chart comparing the times it took to concatenate a given number of strings using both methods. See for yourself and then… use StringBuilders from now on!

String usage

StringBuilder usage

Here’s the source code i used if you want to try it for yourself:

using System;
using System.Collections.Generic;
using System.Text;
 
using Adapdev.Diagnostics;
 
namespace SBuilder
{
    class Program
    {
        static void Main(string[] args)
        {
            HiPerfTimer timer = new HiPerfTimer();
            for (int i = 0; i < 100; i++)
            {
                StringBuilder sb = new StringBuilder();
                timer.Start();
                for (int j = 0; j < 1000 <strong> i; j++)
                {
                    sb.Append(j);
                }
                timer.Stop();
                double timeStringBuilder = timer.Duration;
 
                string s = string.Empty;
                timer.Start();
                for (int j = 0; j < 1000 </strong> i; j++)
                {
                    s += j;
                }
                timer.Stop();
                double timeString = timer.Duration;
 
                StringBuilder line = new StringBuilder();
                line.Append(1000 * i);
                line.Append(";");
                line.Append(timeStringBuilder);
                line.Append(";");
                line.Append(timeString);
                System.Console.WriteLine(line.ToString());
            }
        }
    }
}

You can download the external timer classes from The Code Project.

One of the most interesting features of any good database engine is what we call concurrency. Concurrency means than the database engine should be able to perform a lot of data operations at the same time. This leads to some interesting problems that have a critical impact on another of the features that any database engine must ensure: data consistency.

Sometimes you need to perform more than one non atomic operation in a database that only make sense in a block. This is, all those operations should be executed from the start to the end without any other interference from other operations, because those other operations may have a non desired impact in your operations. The simulation of the atomic execution of more than one operation in databases is done by transactions. When you embrace a set of operations in a transaction, you are telling the database engine that you want those operations to be executed as if they were executed in an isolated mode, this is, with no interference from other operations.

While this might seem easy to accomplish, it can also have a big negative performance impact, because you can’t plan on executing all the transactions that arrive at the same time in a sequential way, at least not if you want your database engine to be slow, very slow.

This is where locks ans isolation levels intervene. Locks are protections made to some resources to allow or forbid further access to those resources by another processes. An exclusive lock, for example, done by a process, means that no other process should be able to access that resource until the first process has freed the lock. There are a lot of different locks in SQL Server, which you can review at http://msdn2.microsoft.com/en-us/library/ms175519.aspx.

One of the problems we can face when working with transactions is the well known repeatable read. Suppose a process A starts a transaction and reads a registry with a select clause in a table. After that, another transaction comes in and modifies that data. The first transaction reads the same data again and gets a different value, becuase it was modified by the second transaction. This is inconsistent, because as we are executing a set of operations inside a transaction, we expect them to be executed as if no one else was modifying the data we need to use.

Because of that, there’s a special isolation level called, precisely, Repeatable Read, which has a locking policy to avoid those problems. But be careful with this, since this can cause a nasty deadlock in your SQL Server if used the wrong way.

A deadlock is a special situation where two or more transactions are waiting each other. Imagine trasaction A starts some operations and locks some resources. Later, transaction B comes in, locks another set of resources, and then tries to access resources locked by A, so it waits for A to free those resources. After that, A tries to lock resources locked by B and wait for B to free them. A is waiting for B to free its resources, and B is waiting for A to do the very same thing. We have a deadlock. One of the transactions must be killed by the database engine and rolled back so the other one can continue. Altough this is something you might be able to control by code and issue a relaunch of the killed transaction, this is something usually not desired.

I’m going to talk now about a deadlock you may face when using the Repeatable Read transaction isolation level with SQL Server 2005. Imagine you have two transactions that do the same thing: read a value, modify it, and read it again. Note that you will be modifying the value, but you set the isolation mode to Repeatable Read (this is, setting the wrong isolation mode by mistake or by ignorance). Transaction A starts and reads the value. SQL Server puts a shared lock on that resource. Transaction B starts and reads the value. Because the lock in A was shared, B can also read that value, gaining a shared lock too. Now transaction B tries to write that value. Because the shared lock put by A was read only, B has to wait for A to release its shared lock to be able to gain write acces to it, so it blocks. After that, A tries to write the value, and because now it’s transaction B that has a shared lock on the resource, it has to wait too. And there it is, the deadlock.

The key in avoiding this is that, although we perform a read-write-read operation, we don’t need the second read to be the same as the first, because we are modifying that resource. In this case, the lock our transactions should get is an update lock, which knows that we’ll be modifying that data after having read it. This way, when transaction A locks the resource, the lock will not be shared, so transaction B will have to wait for A to write the new value before B gets the lock, thus avoiding the deadlock. Another option is use an isolation level that frees the locks just after having read the value, and not maintaining it until the next update.

The conclusion to this is: be careful when working with transactions on which isolation level you use on them, and be sure you’re using the right one if you don’t want to have bug reports when a lof of concurrency starts to stress the database engine!

Imagine you are developing a rails application. Usually you have:

• a terminal with the server to see what petitions are received.
• a terminal with a tail of development.log to see what happens with the database.
• a terminal with a tail of test.log if you are testing something.

This are a lot of windows… And the other day one friends was very happy and after asking for a while I discovered that the reason was the simple line showed above… With only one Ctrl+C you can kill all this processes

script/server & tail -f log/development.log & tail -f log/test.log & tail -f ; jobs -p | awk '{print "kill -2 " $0}' | sh

Today I’ll be discussing a design pattern called Double Check, which can be widely used to manage the resource access, elimination and initialization in a safe thread way.

Consider another common design pattern: the Singleton Pattern. A singleton is a special class which is allowed to have one and only one instance in a program. This pattern can be used in a variety of ways, one of the most usual one is to store global program information, which, as its name states, is global and unique to the application, so having more than one instance of that class would have the burden to mantain them synchronized, or even more nasty consequences.

There are different ways to implement a singleton class. I will focus on C#, but the example shown here could be easily extended to other languages such as C++ or Java. The trick on the pattern consists on declaring the class constructor private. This way we can be sure no one will be creating new instances of that class at will. After having done this, we have to provide a public method, which usually has the name getInstance, that will be the one actually creating this item and returning it to the caller.

The code would look similar to this one:

public sealed class Singleton
{
    private static Singleton instance = null;
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

Another way to create this singleton class would be doing the instantiation of the private variable on the class itself and not on the getInstance method, but this second way gives us a lazy initialization, so the variable is actually instantiated only when it’s needed, and never before (who knows, maybe we will never need it in some circumstances).

This implementation is perfect… as long as this method isn’t called twice (or more) at the same time. Consider what would happen if two threads requested an instance of the singleton class: both threads would check for the instance being null, and both threads would create the instance. That would sure lead to an unknown behaviour, and more than one instance of the class would be in the program, which is exactly what we wanted to avoid.

The first solution that comes in mind is to lock the method so multiple threads must wait to enter the method and get the singleton instance. It would look like this:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            lock(semaphore);
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

This way we ensure that if n threads try to access the routine at the same time, only one will be initializing the singleton instance, since when the others gain the access to the method again, that instance won’t be null anymore. However, even if this solution is valid and works, it has a serious performance problem. Consider the situation where the instance has been already created. Then more than one thread access the routine again to get that instance. What will happen is that those threads will have to block and wait for other threads to finish, even if the instance is not null, so in any case will be created again. Conclusion: we are blocking threads that don’t need to be blocked. “Ok, you may say, we will put the lock inside the if clause, and we’ll have the issue resolved“. Let’s take a look at this solution:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock(semaphore);
                instance = new Singleton();
            }
            return instance;
        }
    }
}

You don’t have to be a genious to see that this is not working, either. It will work after the instance has been created, because the threads won’t be entering the if clause, and they won’t be blocked. But if we are in the same situation as the described in the first place –this is, more than one thread entering the method before the instance has been created–, we have the same problem we had before: the singleton will be created more than once.

The final solution is simple: check again for the variable being null! This is why this pattern is called Double Check. The final code would look like this one:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock(semaphore);
                if (instance == null)
                    instance = new Singleton();
            }
            return instance;
        }
    }
}

This way, we allow the threads to pass by the if clause if the instance has been already instantiated, and if it has not, the threads will get blocked, and the first one to gain access to the method will do the instantiation. Further threads will check again against the instance being null or not, so it won’t be created again.

Altough this pattern may be implemented similarly in other languages, be aware that, as I said before, a lot of them were never intended to deal with multithreading, and that compiler optimizations may give you code which is not really thread safe, or that actually is not optimized. Here you have a link discussing this issue with Java and C++: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.