The Interop dream

Web Services are definitely a step forward in making things work across disparate platforms. The promise is there, but even a trivial thing on how dates are handled across diparate platforms is an issue. In java datetime is a nullable type and in .NET it is not. This is enough to give you headaches. Add to it the timezones and locales another set of issues crop up. Googling lead to some solutions which i am bookmarking for furture references.

 

Interop DateTime Formatting

Caveats using DateTime when building Interoperable Web Services

WSDL.exe Sucks

The Client side code generated by WSDL.exe(VS.NET Add Web Reference) from a WSDL file is not something which everyone will like. The classes generated for the Web Service parameters and return types have public fields instead of properties.

 

This may not be desirable if

• You do some databinding stuff
• Or add some validations on the accessor methods

After googling, the following tools generate a class with getter setter methods.

XSDObjectGen: This generates objects from a XML Schema. It generates property accessors backed up by public fields. It adds an XmlIgnore attribute on the generated property accessors which can be used by your application.

WSContractFirst: A Visual Studio Addin and Command Line utility to enable Contract (WSDL/XSD) first web services development.

svcutil: A Windows Communication Foundation tool. Though this generates classes targetted to be used from WCF this can be customized a bit.

WSContractFirst looks like a good solution to my requirement.

Also on the list is the WSDL tool customized from Mono by Brian Ritchie. But the download link seems to be down. Anyway WSContractFirst looks like a good option. Anything like a CodeSmith Template on this side which is more customizable will be great, and I am googling without much luck on this.

Talking about How to Use Design Patterns? A Discussion with GAMMA

Prakash is linking to some great stuff on Artima. A good read.

Quote

How to Use Design Patterns? A Discussion with GAMMA

Among developers, design patterns are a popular way to think about design, but what is the proper way to think about design patterns? In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about the right way to think about and use design patterns.

 

More here….

http://www.artima.com/lejava/articles/gammadp.html

http://www.artima.com/lejava/articles/reuse.html

http://www.artima.com/lejava/articles/designprinciples.html

http://www.artima.com/lejava/articles/patterns_practice.html

 

Talking about How to learn, write and think more clearly?

 Nice entry from Prakash. It takes atleast 30 minutes though

Quote

How to learn, write and think more clearly?

It is well worth ten minutes as it tells you how to learn, write and think more clearly

 

http://www.ai.uga.edu/mc/WriteThinkLearn_files/frame.htm

Waiting for something to happen – Manual and AutoResetEvents

Assume we have a scenario like this. A component has to call 3 web services to get the data. Instead of calling them one by one in a serial fashion, the component calls them asynchronously. After the component has all the three sets of data, let us say that the component processes the data. It needs to know when all the three method calls complete. One way of doing this is by polling for completion of the three async calls.

 

public class ABusinessComponent {

    public void DoSomething() {

        // Call Web Service 1 Asyncly

        // Call Web Service 2 Asyncly

        // Call Web Service 3 Asyncly

 

        while(service1Done == false && service2Done  == false && service3Done == false) {

            Thread.Sleep(500);

        }

 

        // Do the processing

 

    }

    private bool service1Done = false;

    private bool service2Done = false;

    private bool service3Done = false;

    public void Service1DoneCallback(IAsyncResult arResult) {

       service1Done == true;

    }

    public void Service2DoneCallback(IAsyncResult arResult) {

       service2Done == true;

    }

    public void Service3DoneCallback(IAsyncResult arResult) {

       service3Done == true;

    }

}

 

But polling is generally not a good solution this problem. This can be solved using ManualResetEvents. The main thread calls WaitAll with the three ManualResetEvent objects (one each for a web service call). The same code using ManualResetEvent is given below.

 

public class ABusinessComponent {

    public void DoSomething() {

        // Call Web Service 1 Asyncly

        // Call Web Service 2 Asyncly

        // Call Web Service 3 Asyncly

 

        WaitHandle[] handles = new WaitHandle[] { service1Done, service2Done , service3Done }

        WaitHandle.WaitAll(handles);

         

        // Do the processing

 

    }

    private ManualResetEvent service1Done = new MaunalResetEvent(false);

    private ManualResetEvent service2Done =  = new MaunalResetEvent(false);

    private ManualResetEvent service3Done =  = new MaunalResetEvent(false);

 

    public void Service1DoneCallback(IAsyncResult arResult) {

       service1Done.Set();

    }

    public void Service2DoneCallback(IAsyncResult arResult) {

       service2Done.Set();

    }

    public void Service3DoneCallback(IAsyncResult arResult) {

       service3Done.Set();

    }

}

 

When a ManualResetEvent is created it is created in non-signalled state. Calling the static method WaitAll on the WaitHandle class passing the three manual reset events in non-signalled state puts the calling thread into WaitSleepJoin state. Once all the three service calls are done (and all the set methods are called) all the manual reset events are signalled now. This makes the main thread schedulable again.

 

Assume the samething happens in a loop using a auto reset event eliminates the need for calling reset.

 

public class ABusinessComponent {

    public void DoSomething() {

        // Do the statements below in a loop

     // begin loop

        // Call Web Service 1 Asyncly

        // Call Web Service 2 Asyncly

        // Call Web Service 3 Asyncly

 

        WaitHandle[] handles = new WaitHandle[] { service1Done, service2Done , service3Done }

        WaitHandle.WaitAll(handles);

         

        // Do the processing

      // end loop

 

    }

    private AutoResetEvent service1Done = new AutoResetEvent(false);

    private AutoResetEvent service2Done =  = new AutoResetEvent(false);

    private AutoResetEvent service3Done =  = new AutoResetEvent(false);

 

    public void Service1DoneCallback(IAsyncResult arResult) {

       service1Done.Set();

    }

    public void Service2DoneCallback(IAsyncResult arResult) {

       service2Done.Set();

    }

    public void Service3DoneCallback(IAsyncResult arResult) {

       service3Done.Set();

    }

}

 

A cross process synchronization – Mutex

Let us take the same Logger class. Assume the library is used by multiple processes, That would still result in out-of order execution. How can we synchronize across processes? The Mutex class comes to our rescue. The Logger example rewritten using a mutex is given below:

public class Logger {

    private static StreamWriter writer;

    private static Mutex writerLock;

    static Logger() {

        // read fileName from config or something else

        writer = new StreamWriter(fileName);

        writerLock = new Mutex(false, "Global\WriterLock");

    }

    public static void Log(string source, string category, string message) {

        try {

            writerLock.WaitOne();

            writer.WriteLine("—————————————————————————-");

            writer.WriteLine("Source: " + source);

            writer.WriteLine("Date & Time: " + DateTime.Now.ToString("dd/MM/yyyy HH:mm"));

            writer.WriteLine("Category: " + category);

            writer.WriteLine("Message: " + message);

            writer.WriteLine("—————————————————————————-");

        }

        finally {

           writerLock.ReleaseMutex();

        }

    }

}

This is similar to the Monitor.Enter and monitor.Leave. WaitOne checks to see if another thread owns the mutex. If not this thread can enter the critical section and becomes the owner of the mutex. If another thread owns the mutex the calling thread is put into a WaitSleepJoin state and remains in that state till the original owner of the mutex call ReleaseMutex.

Waiting for something to happen – WaitHandles

Assume two threads want to acquire a lock. Say thread 1 aquires it first. Thread 2 would like to know when Thread 1 has released the lock. This is the second case of inter thread communication issue which we discussed in the Multi-Threading basics – Setting the state article.

One way is to poll continuously to check if Thread 1 has released the lock. This solution would result in wasting precious CPU cycles. There should be some way to make a thread wait till someting of interest happens and be notified of the event of interest. The waiting thread becomes notified and awakens when the event occurs without resorting to polling.

As we discussed earlier kernel objects are either signalled or non-signalled. The Win32 API WaitForSingleObject puts the calling thread into Wait till the kernel object passed becomes signalled. If you call WaitForSingleObject passing a signalled object, the calling thread can run. If you call WaitForSingleObject passing a non-signalled kernel object the calling thread has to wait till the object becomes signalled.

The same is encapsulated in the object oriented .NET Framework by the WaitHandle class. A WaitHandle can be either in a signalled or non-signalled state. WaitOne stands in as a equivalent for the WaitForSingleObject Win32 API. If you think the discussion is at a too abstract level then that’s because this WaitHandle is an Abstract class. Mutex, AutoResetEvent and ManualResetEvent are concrete classes which derive from Waithandle and provide you waiting abilities.

 

Critical Sections of code – Monitor

Consider that you are writing a Logger library. Assume this logs contents to a file. Initial design of the library is something like this:

public class Logger {

    private static StreamWriter writer;

    static Logger() {

        // read fileName from config or something else

        writer = new StreamWriter(fileName);

    }

    public static void Log(string source, string category, string message) {

        writer.WriteLine("—————————————————————————-");

        writer.WriteLine("Source: " + source);

        writer.WriteLine("Date & Time: " + DateTime.Now.ToString("dd/MM/yyyy HH:mm"));

        writer.WriteLine("Category: " + category);

        writer.WriteLine("Message: " + message);

        writer.WriteLine("—————————————————————————-");

    }

}

Let us say that this logger is going to used by a single threaded application. Things will work fine. Assume the same logger is now distributed to a multi-threaded application. 

Thread A calls logger with "Source: BusinessLayer – ClaimsProcessor", "Category: Warning", "Message: Blah Blah Blah"

Thread B calls logger with "Source: DataLayer – ClaimsProcessor", "Category: Error", "Message: Something serious has happenned"

 

Thread A	Thread B
writes the source	Suspended
Context-Switch	Context-Switch
Suspended	writes the source
Context-Switch	Context-Switch
writes the datetime	Suspended
Context-Switch	Context-Switch
Suspended	writes the datetime
Context-Switch	Context-Switch
writes the Category	Suspended
Context-Switch	Context-Switch
Suspended	writes the Category
Context-Switch	Context-Switch
writes the message	Suspended
Context-Switch	Context-Switch
Suspended	writes the message
Context-Switch	Context-Switch

The result will be messy due to the out of order execution.

How do you avoid this data corruption?

This can be avoided if we can ensure that only one thread executes this ‘critical section’ of code at a time. Assoicate this section of code with a lock object. Lock the object. Execute this section of code. Release the lock. If another thread tries to acquire a lock it has to wait till the this thread releases a lock. This can be achieved in .NET using the Monitor class. Let us rewrite the code using the Monitor class.

 

public class Logger {

    private static StreamWriter writer;

    static Logger() {

        // read fileName from config or something else

        writer = new StreamWriter(fileName);

    }

    public static void Log(string source, string category, string message) {

        try {

            Monitor.Enter(writer);

            writer.WriteLine("—————————————————————————-");

            writer.WriteLine("Source: " + source);

            writer.WriteLine("Date & Time: " + DateTime.Now.ToString("dd/MM/yyyy HH:mm"));

            writer.WriteLine("Category: " + category);

            writer.WriteLine("Message: " + message);

            writer.WriteLine("—————————————————————————-");

        }

        finally {

           Monitor.Leave(writer);

        }

    }

}

 

We have associated the ciritcal section of code with the lock by the calling Monitor.Enter.

Monitor.Leave releases the lock. We have this code in finally as we need the lock to be released even in the case of exceptions. When a thread calls Monitor.lock passing the writer object. The framework checks if the witer object is locked already. If it is not this thread acquires the lock. Else this thread goes into wait till the writer object is released.

 

The above pattern of code is so common in the framework that the languages C#, VB.NET support them using the lock and SyncLock blocks repectively.

 

lock(someObject) {

    // Execute Critical Section of code

}

 

exapnds to

 

try {

    Monitor.Enter(someObject);

    // Execute Critical Section of code

}

finally {

    Monitor.Leave(someObject);

}

A monitor cannot be used to synchronize access across processes. The same has to be done using Mutex if it has to be across processes.

Atomic access functions – Interlocked family of functions

How do we avoid races?

Recall the example we discussed when we were discussing about the race condition. This could be avoided by using the Interlocked family of funtions. The interlocked family of functions guarantee that another thread cannot pre-empt the running thread when executing a atomic instruction.

 

public class QueueHandler

{

            private int itemsInQueue;

 

            public void ProcessItem();

            {

                        // Process Item

                       

                        // Decrement itemsInQueue

                        Interlocked.Decrement(ref itemsInQueue);

                       

                        if (itemsInQueue != 0)

                        {

                                    // Queue another work item for ProcessItem

                        }

            }

}

 

Other Interlocked members:

public static int Decrement(ref int);

public static long Decrement(ref long);

public static int Increment(ref int);

public static long Increment(ref long);

public static int Exchange(ref int, int);

public static object Exchange(ref object, object);

public static float Exchange(ref float, float);

public static int CompareExchange(ref int, int, int);

public static object CompareExchange(ref object, object, object);

public static float CompareExchange(ref float, float, float);

 

Exchange

Sets an object/int/float to a specified value as an atomic operation, and returns a reference to the original object/int/float.

 

CompareExchange

Compares two objects for equality and, if they are equal, replaces one of the objects.

 

What do we do if our critical section of the code (code which manipulates the shared data – just the decrement in this case) is not just decrement, increment, swap or compare and swap? How do we avoid races in such a case? Let us see this with an example in an upcoming article.

Thread States in .NET

What are the various thread states?

The following diagram gives an idea of the various thread states and the transition between them.

 

Action	ThreadState
A thread is created within the common language runtime.	Unstarted
A thread calls Start The thread starts running.	Running
The thread calls Sleep	WaitSleepJoin
The thread calls Wait on another object.	WaitSleepJoin
The thread calls Join on another thread.	WaitSleepJoin
Another thread calls Interrupt	Running
Another thread calls Suspend	SuspendRequested
The thread responds to a Suspend request.	Suspended
Another thread calls Resume	Running
Another thread calls Abort	AbortRequested
The thread responds to a Abort request.	Stopped
A thread is terminated.	Stopped

A note on the background threads:

The frmaework categorizes threads into two flavours background and foreground. This is controlled by the IsBackground property on a thread. When all the Foreground threads in a process terminate the process terminates irrespective of whether background threads are running or not. When atleast one foreground thread is there, the process cannot terminate. When there are no foreground threads even if there are background threads running the process terminates.