



After a quite while, I’d a chance to start looking into Windows Server AppFabric. This is one my long pending middler tier component from Windows/.NET combo.
A set of components provide service hosting, in-memory caching, stateful services persistence and management services, management consoles and API to access these services. The following figure shows the major responsibilities of AppFabric components.
Hosting services extends WAS (Windows Process Activation Service) with some default configuration, workflow management and, administration tools. In-memory caching, previously code-named as Velocity, is a solution for scalable caching of enterprise/web applications. Its cluster architecture and provision to configure various caching options enable us to prepare feast for small to large crowd. Not know in detail about what makes different from WF 3.x and SQL Server combo, and state persistence service in AppFabric. Let us see in detail on future logs. To manage these aspects, AppFabric provides variety of management services which includes dashboard, service deployment, monitors and APIs.
Windows Server AppFabric is actually designed for Windows 2008, but has development stage avatars for Windows Vista/7. AppFabric beta 1 targetedc .NET 4.0 beta 2 and AppFabric beta 2 is targeted .NET 4.0 RC. It will act as extension of IIS 7.0. The following figure shows the IIS MMC for this.
The Windows 7/2008 beta 1 can be downloaded at http://download.microsoft.com/download/0/A/E/0AEB3BC1-506E-4954-8AB1-4FA2EE75985C/AseSetup_x86_6.1.exe.
Beta 2 can be downloaded at http://download.microsoft.com/download/F/D/4/FD4F05A5-016B-40F8-A61F-1D38E202A32A/WindowsServerAppFabricSetup_x86_6.1.exe.




In my previous post, we have seen basis of Task Parallel Library, where I have mentioned new task scheduler in .NET 4.0 thread pool. In this post I brief about it along with “Task” class. Before this, let us see how to make LINQ as parallel using PLINQ.
PLINQ has implementation of all LINQ to Objects extension methods in System.Linq.ParallelEnumerable for IEnumerable. To make an IEnumerable parallel, you simply call AsParallel() extension method. AsParallel() internally calls System.Linq.Parallel.ParallelEnumerableWrapper which is of type System.Linq.ParallelQuery<TSource>. Let us take the same customer-order example as shown in my previous post with PLINQ enabled.
var customersForOrderId7 = from c in customers.AsParallel() from o in c.Orders where o.OrderId == 7 select c; customersForOrderId7.ForAll(c => Console.WriteLine(c.ToString()));
The above code selects customers who have ordered OrderId 7. AsParallel() at line 3 makes Customer[] as parallel enabled. In this example, you can see that instead of typical for…each, I’ve used ForAll(). This differs from for..each, means that for..each preservs the final order of the results.
Until .NET3.5, we can queue our work items as thread in to ThreadPool using QueueUserWorkItem(). In .NET 4.0, improvements had been made in the thread pool. It is now based on System.Threading.Tasks.Task.
Task is a work item which can be executed independently along with other tasks, technically it represents an asynchronous operation i.e. System.Action. It is defined in System.Threading.Tasks.Task which enables you to do the following actions on a task instance:
It seems that task is a lite version of thread.
Following diagram shows the conceptual view of .NET 4.0 thread pool.

Previously, thread pool had only one queue on which all the work items were queued and enqueued in FIFO order (ofcourse, thats why queue). The worker threads are allocated for every work item access the work item from this queue. In .NET 4.0, it has been improved by introducing local queue for every worker thread, in addition to qlobal queue. Tasks those are created by program thread queued on global queue. The task scheduler enqueues the tasks from global queue in FIFO order and distributes to respective worker thread’s local queue. The worker thread enqueues the tasks from its local queue in LIFO order. Interesting!
The introduction of local queue makes these threads can be executed on different processors without contention issue which normally occur in single queue thread pool. The reason for worker thread picking up the tasks in LIFO order is the assumption that “last-in” is hot to act which results no qurantee in task ordering, but better performance.
Let us assume that worker thread 1 completed all of its tasks in the queue. It scans the global queue for any task and if nothing there, it scans other worker thread’s local queue. In this case, let us assume there are two tasks in WT2 queue. WT1 enqueues first-in task from WT2 queue which avoids contention issue. Getting tasks from other local queue is called as work stealing. This again results better performance.
MSDN article: Task Parallel Library Overview: http://msdn.microsoft.com/en-us/library/dd460717(VS.100).aspx
Daniel Moth’s videocast and PPT deck: http://channel9.msdn.com/pdc2008/TL26/ and his article about thread pool at http://www.danielmoth.com/Blog/2008/11/new-and-improved-clr-4-thread-pool.html
My Code sample for PLINQ as used in this post is at http://www.udooz.net/file-drive/doc_details/9-tpl-and-plinq-example.html




We are in the multi-core era, where our applications are expected to effectively use these cores. Simply, go parallel, means that partitioning the work being done into smaller pieces those are executed on the available processors in the target system. Until .NET 3.5, parallel means we are used to use ThreadPool and Thread classes. We are not in a situation to have a component which partition and schedule work into work items on different cores. A craft-and-weave parallel framework from Intel is available while for MC++ and not sure how easy it is to use.
Even though threads are basic to parallel, from a developer perspective, what required for parallel programming is not the thread, work items in a work, named “Task”.
Task represents a work item being performed independently along with other work items. This is the approach taken by the experts in Microsoft Parallel Computing division, and released parallel extensions (Task Parallel Library and Parallel LINQ) in .NET 4.0 beta 1. As like Microsoft’s other frameworks, developers need not worry about the internals. The task partitioning and scheduling of the work items are taken care by parallel extensions.
Let us first understand the relationship between task and thread. See the following figure.

Typically task is resided in a thread. A task may contain one or more child tasks those are not necessarly resided in the parent task’s thread. In the above figure, Child Task M2 of Task M resided in Thread B.
This library provides API to perform task based parallel programming under System.Threading and System.Threading.Tasks namespaces. The partitioned tasks are automatically scheduled on available processors by Task Scheduler which is in ThreadPool. The work stealing queue algorithm in the task scheduler makes the life easier. I’ll explain about this in the next post.
Scheduling the tasks on the processors is the runtime behaviour of the task scheduler, so it does support ’scale up’ without recompiling the program on the target machine with few or more cores.
There are two types of parallelism you can do using TPL.
It is very common to perform a set of actions against each element in a collection of data using for and for..each. Parallel.For() and Parallel.ForEach() enable to make your collection processing actions to be parallel. The following figure depicts this.

Let us see this with typical customer-order collection. The following code shows Customer and Order declaration.
public class Customer
{
public string Name;
public string City;
public Order[] Orders;
public override string ToString()
{
return String.Format("Name: {0} - City: {1}",
Name, City);
}
}
public class Order
{
public int OrderId;
public int Quantity;
public override string ToString()
{
return String.Format("Order Id: {0} - Quantity: {1}",
OrderId, Quantity);
}
}
Let us create a in-memory collection for this as like below code.
var customers = new Customer[]
{
new Customer{Name="Hussain", City="Vizak", Orders =
new Order[]
{
new Order{OrderId=1, Quantity=10},
new Order{OrderId=10, Quantity=5}
}},
new Customer{Name="Abdul", City="Chennai", Orders =
new Order[]
{
new Order{OrderId=7, Quantity=2},
new Order{OrderId=10, Quantity=4}
}},
new Customer{Name="Daniel", City="Texas", Orders =
new Order[]
{
new Order{OrderId=12, Quantity=3},
new Order{OrderId=7, Quantity=1},
new Order{OrderId=10, Quantity=1}
}}
};
Let us write a simple parallel code which iterate through each customers and its orders.
Parallel.ForEach<Customer>(customers,
customer =>
{
Console.WriteLine("**** {0} ****", customer.ToString());
Parallel.ForEach<Order>(customer.Orders,
order =>
{
Console.WriteLine("\t{0}", order.ToString());
});
});
In the above code, printing customer detail is one task and printing order detail for a specified customer is the child one for that. I’ve taken simple overloaded version of For…Each
public static ParallelLoopResult ForEach<TSource>(IEnumerable<TSource> source, Action<TSource> body);
The task scheduler partitions the customers and orders, and schedule them into available processors.
In cases like multiple distinct actions to be performed concurrently on the same or different source. The following figure depicts this. Note that task count need not be equal to number of actions.

Parallel.Invoke() is used for this. See the following code.
Parallel.Invoke(() =>
{
Console.WriteLine("Task 1. Getting total quantity ordered for OrderId 10");
var orderId10Sum =
(from c in customers
from o in c.Orders
where o.OrderId == 10
select o.Quantity).Sum();
Console.WriteLine("Quantity: {0}", orderId10Sum);
},() =>
{
Console.WriteLine("Task 2. Getting number of customers and their city ordered OrderId 7");
var items =
from c in customers
from o in c.Orders
where o.OrderId == 7
select c.City;
Console.WriteLine("Count: {0}\nFrom following City:", items.Count());
foreach (string city in items)
Console.WriteLine(city);
}
);
I’ve taken the following overloaded version of Parallel.Invoke().
public static void Invoke(params Action[] actions);
I’ve specified two different actions those are acted on customers.
The source code for this article is available at http://www.udooz.net/file-drive/doc_details/8-net-40-tlp-demo-1.html.
In the next post, I’ll explain the more about tasks, Parallel LINQ portion and task scheduler.


More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 