SS

Have you ever thought of a situation in which two threads need to communicate between each other? Let’s suppose one is a producer thread which produces data which will be used by a consumer thread. The obvious method to tackle this issue is to keep a common buffer right between them where the producer dumps its data into the buffer and the consumer reads the same. The one and only over head involved is that of, when the write operation is done the buffer will be locked by the producer thread. So the consumer thread has to wait until the buffer is released before it starts reading. This approach is fine until situation become some thing like the number of transactions between the threads goes around few thousands/sec. In fact situations like that occurs very frequently in game servers which require thousands of requested to be handled on per second basis. In such demanding situations the performance seem to come down drastically just because the consumer thread is put on hold when ever a write operation is on.

One good  solution for this problem is the Ring buffer. The idea is simple and classy. They use 2 pointers one for read and one for write. Using write pointer the data is written into the buffer while the read pointer reads the written data. When the read pointer and write pointer points to the same location, the buffer is empty. One important condition that needs to be checked out is that of the read pointer overtake write pointer, you know what happens

The concept of Spin buffers is a direct extension of the Ring buffer. Spin buffers contains three internal “ordered” buffers. The buffers are ordered as 0, 1, and 2. Two pointers are maintained — one that points to a buffer that a reader reads from, and another one that writes. At any time there can be an assigned read buffer (R), an assigned write buffer (w), and free one (f). The buffers can be implemented as fixed-sized arrays.

Now lets take a look at how write method is implemented:

1. Put the item into the write buffer.
2. If the next buffer is free, make the free buffer become the write buffer, and the current write buffer becomes free. 

It’s just the vice-versa with read method: 

1.  Read the item from the read buffer.

2.  If the current read buffer is empty and the next buffer is free, make the next buffer the read buffer, and the current read buffer becomes free.

 But you might be thinking where is that big advantage that you where hyping about. Look closely and you will notice the whole idea doesn’t involve any level of synchronization between the read and write methods. This means there is no dependency on each other and no one waits for the other. No locks means no wait means lots of time saved.

This is one of the most popular design patterns which have been widely adopted in applications which require multiple views of the same data. Typical examples of such applications are web based client-server applications in which many servers are busy browsing through our database and presenting data in different flavors to please a million users staring at their browsers. 

The primitive and blunt way of creating such applications was to integrate whole of the view and the logics into a single layer which is tightly linked to each other and also to the data representation back in the database. So when ever a change occurs at the database layer it directly affects the code written at the logics level since they are dependent on each other. Similar is the situation when you try to make a UI change you are unnecessarily ploughing through the logics code. It just mess-up the whole production in fact it becomes impossible to maintain and test such applications. 

With MVC pattern, first and foremost aim was that of a clean separation of objects into one of three categories — models for maintaining data, views for displaying all or a portion of the data, and controllers for handling events that affect the model or view(s).Model is a data representation which holds ALL the data of the application structured based on the domain. In fact it represents the whole of the data on which the application stands on. The controller is the logics part which  handles events triggered from the browser and makes corresponding changes to the model/View. 

The MVC abstraction can be graphically represented as follows.

Events typically intimates the controller to change a model, or view, or both. Whenever a controller changes a model’s data or properties, all dependent views are automatically updated. Similarly, whenever a controller changes a view, for example, by revealing areas that were previously hidden, the view gets data from the underlying model to refresh itself.

Lets explain the MVC pattern with the help of a simple component which consists of a text field and two arrow buttons that can be used to increment or decrement a numeric value shown in the text field.

The data is held in a text model that is shared with the text field. The text field provides a view of the current value. Each click on the arrow button  is an event source, that triggers an action event every . The buttons can be hooked to an action listener that eventually handles that event. Depending on the source of the event, the action listener either increments or decrements the value held in the model — The action listener is an example of a controller.The text model represent the model and the text box control - the view.

PS : Dig more on MVC here!

So the basic question - what the hell is a Pattern? .In software industry certain techniques has been used over and over again for tackling common design issues. These collections of most commonly used techniques are called Design patterns. 

This whole new adventure with patterns caught my interest very recently when our architect Nicholas Manson talked a bit too much about what all patterns he used in our project. I was bit puzzled at my ignorance towards some thing so basic and interesting. So as a matter of selfrespect I thought its time for some digging, emmm may be the easiest one to start with…the MVC pattern; you are right, we have heard bout it a thousand times ‘Model-View-Controller’. But for my surprise the amount of depth involved in this architecture just puzzled me up. It din take much time before I realized MVC pattern is not just about a view and model being manipulated by a controller, in fact it is an elegant integration of many smaller patterns. So I decided its time to dive deep and to spend some quality time with regard to this matter. So as and when I get hold of these little guys I will be coming up with some compilations, may be very soon.