Of course, the fact that widely used operating systems support multithreading is also a factor. Whatever the reasons, the increased use of multithreading is changing the way that programmers think about the fundamental architecture of a program.

Although C++ does not contain built-in support (*) for multithreaded programs, it is right at home in this arena.

In this blog we will have a look at some features of multithreaded support in the Qt-Framework.

Qt is a cross–platform application development framework, originally developed and released by Trolltech, a Norwegian company. It is used to develop desktop as well as embedded GUI applications. Qt is written in C++ and is fully object-oriented.

At the moment Qt supports Windows, Linux/X11, Mac OS X, Embedded Linux, Symbian and Windows CE.

(*This is true for the old C++03 standard. In C++11 there is now a standard threading library.)

Multithreading support in Qt

Multithreading with Qt was supported from the first days. Since Release of Qt 4.4 some changes in the basic concepts were introduced, which change the way we can implement multithreaded applications.

First let us have a look at the old way of implementing multithreading in Qt and afterwards we will give two examples of the new approaches.

(For the examples shown we used Qt 4.8 with Microsoft Visual Studio 2010 and the Qt Add-in 1.1.10.)

Multithreading, the Old Style

QThread is the working horse for concurrent programming. QThread is a very convenient cross platform abstraction of native platform threads.

It offers some simple operations for threading such as for starting, stopping threading, querying the state of the threading state, setting the priority of the thread, etc.

Before release Qt 4.4, the original QThread class was abstract, so sub-classing was necessary. This is comparable to the java style of threading-implementation, which meant creating a sub-class of QThread and implementing the run method. Here is an example in the old style:

class SampleThread : public QThread
{
   Q_OBJECT

   protected:
   virtual void run()
   {
      // do some work
      qDebug() << "Hello from SampleThread: Thread Id:" << QThread::currentThreadId();

      // Enters the main event loop and waits until exit() is called.
      exec();
   }
};

Now some manipulations with the thread:

SampleThread aThread;
// start thread
aThread.start();
// check if thread running, returns true
qDebug()<< "thread running " << aThread.isRunning();
// check if thread finished, returns false
qDebug()<< "thread finished" << aThread.isFinished();

// terminate thread and wait for termination
aThread.quit();
aThread.wait();

// check if thread running, returns false
qDebug()<< "thread running " << aThread.isRunning();
// check if thread finished, returns true
qDebug()<< "thread finished" << aThread.isFinished();

This is a programming paradigm that many multithreading libraries follow, with classes such as QMutex, QWaitCondition and QFuture.

QThread objects can communicate with each other by posting events with QCoreApplication::postEvent(QObject* receiver, QEvent* event) and processing them by overriding the operation bool QObject::event(QEvent* e).

Here an example:

virtual bool event ( QEvent * e )
{
   if (e->type() == QEvent::User)
   {
      qDebug() << "Processing event";
      //...
      return true;
   }
   return false;
}

To synchronize threads we can use QWaitCondition. QWaitCondition provides a condition variable for synchronizing threads. In the caller thread you would call “wakeOne” to wake up one of many server objects or “wakeAll” to wake them all up.

In the server thread you wait on a locked QMutex object.

Let’s have a look at an example:

A client class cyclically calls “callWake” to wake up one or all server objects. The server objects wait on a QMutex object and log out some text when triggered.

class Client : public QThread
{
   Q_OBJECT
   public:
   Client(QWaitCondition* cond):
      QThread(0),
      mpWaitCondition(cond){}
   protected:
   void run()
   {
      while(true)
      {
         sleep(1);
         callWake();
      }
   }
   private:
   void callWake()
   {
      // wake up the Server objects
      mpWaitCondition->wakeOne();
      //mpWaitCondition->wakeAll();
      qDebug() << "client  called wake all,.thread:" << QThread::currentThreadId();
   }

   QWaitCondition* mpWaitCondition;
};

class Server : public QThread
{
   Q_OBJECT
   public:
   Server(QWaitCondition* cond):QThread(0),
      mpWaitCondition(cond){}
   protected:
   void run()
   {
      while (true)
      {
         QMutexLocker locker(&mutex);
         mpWaitCondition->wait(&mutex);
         qDebug() << "Server triggered,........thread:" << QThread::currentThreadId();
      }
   }

   private:
   QWaitCondition* mpWaitCondition;
   QMutex mutex;
};

Now let’s instantiate the classes and see what happens:

QWaitCondition mCond;

Client client(&mCond);
Server server1(&mCond);
Server server2(&mCond);

server1.start();
server2.start();
client.start();

The output with “wakeOne” shows that only one of the two server objects is woken up.

client  called wake all,.thread: 0x1b70
Server triggered,........thread: 0x2438
client  called wake all,.thread: 0x1b70
Server triggered,........thread: 0x1a6c
client  called wake all,.thread: 0x1b70
Server triggered,........thread: 0x2438

Replacing “wakeOne” with “wakeAll” shows the expected output. Both servers are triggered:

client  called wake all,.thread: 0x1814
Server triggered,........thread: 0x1f94
Server triggered,........thread: 0xd7c
client  called wake all,.thread: 0x1814
Server triggered,........thread: 0x1f94
Server triggered,........thread: 0xd7c

Multithreading, the new Style

With Qt 4.4 some basic changes were added:

• Thread affinity was introduced at the base level of QObject, which is the base object for nearly all Qt related classes.
• Signal and slot connections can now be used between objects of different thread affinity.
• QThread gained a default run implementation.

These changes allow us to implement multithreading in another more elegant way.

In the following example we want to implement a simple ping-pong with different threads. Here a sequence diagram of what we intend to code:

A ping object in thread “ClientThread” sends a “sendPing” to an object pong in “ServerThread”. The pong object sends back a “sendPong” to the ping object. The object ping starts a timer and sends back a “sendPing” at timer expiration.

The Ping class:

class Ping : public QObject
{
   Q_OBJECT

signals:
   void sendPing();

public slots:
   void startTimerForPing()
   {
      qDebug() << "Ping::startTimerForPing,......Thread Id:" << QThread::currentThreadId();
      QTimer::singleShot(100, this, SLOT(timeoutSendPing()));
   }

   void timeoutSendPing()
   {
      qDebug() << "Ping::timeoutSendPing,........Thread Id:" << QThread::currentThreadId();
      emit sendPing();
   }
};

The Pong class:

class Pong : public QObject
{
   Q_OBJECT

signals:
   void sendPong();

public slots:
   void receivePing()
   {
      qDebug() << "Pong::receivePing, sendPong,..Thread Id:" << QThread::currentThreadId();
      emit sendPong();
   }
};

Now let’s instantiate the classes and connect the signals and slots:

// example pingpong
Ping ping;
Pong pong;

// connect the signals and slots *
pong.connect(&ping, SIGNAL(sendPing()), SLOT(receivePing()));
ping.connect(&pong, SIGNAL(sendPong()), SLOT(startTimerForPing()));
ping.connect(&ClientThread, SIGNAL(started()), SLOT(startTimerForPing()));

QThread ClientThread;
QThread ServerThread;

// move the objects ping and pong to another thread.
// (i.e. set the thread affinity of the objects)
ping.moveToThread(&ClientThread);
pong.moveToThread(&ServerThread);

ClientThread.start();
ServerThread.start();

When we start it we get:

Ping::startTimerForPing,......Thread Id: 0x4318
Ping::timeoutSendPing,........Thread Id: 0x4318
Pong::receivePing, sendPong,..Thread Id: 0x419c
Ping::startTimerForPing,......Thread Id: 0x4318
Ping::timeoutSendPing,........Thread Id: 0x4318
Pong::receivePing, sendPong,..Thread Id: 0x419c
Ping::startTimerForPing,......Thread Id: 0x4318
Ping::timeoutSendPing,........Thread Id: 0x4318
Pong::receivePing, sendPong,..Thread Id: 0x419c
Ping::startTimerForPing,......Thread Id: 0x4318

The interesting thing here is the QObject::connect() method, which connects signals and slots:

bool QObject::connect(const QObject *sender,
                      const char *signal,
                      const QObject *receiver,
                      const char *method,
                      Qt::ConnectionType type = Qt::AutoConnection);

The last parameter is the connection type and it is important to understand it.

The default value is Qt::AutoConnection, meaning that if the signal is emitted from a different thread than the receiving object, the signal is queued, behaving as Qt::QueuedConnection (asynchronous). Otherwise, the slot is invoked directly (synchronous), behaving as Qt::DirectConnection. The type of connection is determined when the signal is emitted.

However you can override the behavior: To synchronously call one thread from another you could use Qt::BlockingQueuedConnection meaning that the call will return after it was processed.

But be aware that you could run into big trouble, such as a deadlock. Let us create a deadlock situation by modifying the code above:

pong.connect(&ping, SIGNAL(sendPing()), SLOT(receivePing()), Qt::BlockingQueuedConnection);
ping.connect(&pong, SIGNAL(sendPong()), SLOT(startTimerForPing()), Qt::BlockingQueuedConnection);
ping.connect(&ClientThread, SIGNAL(started()), SLOT(startTimerForPing()), Qt::BlockingQueuedConnection);

When we start the example we get following output:

Qt: Dead lock detected while activating a BlockingQueuedConnection: Sender is QThread(0x20fbb8), receiver is Ping(0x20fba0)

So, at least we have some hints of a deadlock situation.

Class QThreadPool

QThreadPool was also introduced with Qt 4.4. It manages and recycles individual QThread objects to help reduce thread creation costs in programs that use threads. For performance reasons it is recommended that QThreadPool contains the same number of threads as the number of available cpu-cores.

QThreadPool expects an object of type QRunnable to execute it in a thread.

class MyRunnable : public QRunnable
{
public:
   void run()
   {
      // the code you want to execute in a separate thread
      qDebug() << "MyRunnable::run start, Thread Id:" << QThread::currentThread();
   }
};

Let’s put it all together:

MyRunnable* pWork = new MyRunnable();
pWork->setAutoDelete(false);
QThreadPool *threadPool = QThreadPool::globalInstance();

// gives the number of
qDebug() << "maxThreadCount:" << threadPool->maxThreadCount();
// start the work
threadPool->start(pWork);
…
// do something else
threadPool->waitForDone();

You might have noticed the command “setAutoDelete”. If we do not set it, the object will be deleted after termination by the QThreadPool object itself. So if you need to access the MyRunnable object after processing to get any results out of it, it is required to set auto-delete to false.

Summary

In this short overview we have seen that Qt provides quite a good foundation for platform independent multithreading in c++. The possibilities of Qt have become even better with the arrival of Qt 4.4. It allows us to write multithreaded application in a more elegant way.

At the moment we are waiting for the official release of Qt 5, which will also introduce some exciting new features.

For more information have a look at http://qt-project.org

What is it?

Gradle is a build system that combines and extends the best features of Ant and Maven. It supports task based build processes like Ant and follows convention over configuration like Maven. On top of that, Gradle build scripts are written in the Groovy language allowing to define more complex behaviour in cases where it is necessary. But you don’t need to be a Groovy expert because Gradle comes with a domain specific language (DSL) to define the builds.

Dependencies can be managed using Ivy and Maven repositories or by yourself if that is required. Most of the behaviour is defined in Gradle plug-ins that ship with its distribution. They can be used out of the box and adapted to your needs.

A simple example

A simple example of a build.gradle script for a Java project looks like this:

apply plugin: 'java'

It expects the default layout from Maven which consists of src/main/java, src/main/resource, src/test/java and src/test/resource. And it expects the source to be compatible with the current JVM it is running on. To change these properties of the ‘java’ plug-in you can use Gradle’s DSL:

sourceSets.main.java.srcDirs = ['src/java', 'src/generated']
sourceCompatibility = 1.6

Dependency management

Repositories

Gradle can access Maven and Ivy repositories. Here are some samples how to configure the repositories:

repositories {
  mavenLocal()
  maven {
    url "http://repo.mycompany.com/repo"
  }
  mavenCentral()
}

repositories {
  ivy {
    url "http://repo.mycompany.com/repo"
  }
}

The look-ups will be done in the order given within the repositories section. So in the above Maven example it will first look in the local repository of the user, then on the company’s server and finally on Maven Central.

Dependencies

To depend on an internal module, i.e. a module from the same project, you just write:

dependencies {
  compile project(':shared')
}

You can also add dependencies to external modules from Maven or Ivy repositories if you have defined them as described above.

dependencies {
  runtime group: 'org.hibernate', name: 'hibernate', version: '3.0.5'
  testRuntime 'org.mockito:mockito-core:1.8.4'
}

The above sample contains the long and the short version of a module identifier. If you have a dependency on a local file then you can specify it with:

dependencies {
  compile files('libs/a.jar', 'libs/b.jar')
  testCompile fileTree(dir: 'testlibs', include: '*.jar')
}

More sophisticated features can be found in the documentation and include stuff like:

• overwriting transitive dependencies
• use Ivy specific dependency features
• etc.

Tasks

Tasks are the central building blocks of the build process. They consist of two lists of actions. One list is to configure the task and the other to execute it. Here is a sample:

// Just define an empty task
task myTaskA

// Add a configuration action
myTaskA {
  println "config A"
}

// Add an execution action
myTaskA << {
  println "action A"
}

// Another task depending on myTaskA with configuration and action
task myTaskB (dependsOn: myTaskA) {
  println "config B"

  doLast {
    println "action B"
  }
}

Now you can start it:

$ gradle myTaskB

The configuration steps will be executed first. And since myTaskB depends on myTaskA the output will be:

config A
config B
:myTaskA
action A
:myTaskB
action B

BUILD SUCCESSFUL

Tasks can also be of a predefined type. The follwoing example uses the JavaExec type to start some Java code:

apply plugin: 'java'

… // dependencies, repositories etc.

task startMain(type: JavaExec, dependsOn: classes) {
  main = 'mypackage.Main'
  args = "-x -y -z".split().toList()
  classpath sourceSets.main.classesDir
  classpath configurations.compile
}

The command gradle startMain prepares the classes and then starts the program using the classes and also the external dependencies as classpath.

Maven sample comparison

Just to be clear: this is not an A is better than B comparison. The purpose is only to show you the two different versions of a Maven and a Gradle build script that achieve the same thing.

<project xmlns="http://maven.apache.org/POM/4.0.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

   <modelVersion>4.0.0</modelVersion>

   <groupId>ch.bbv.mavendemo</groupId>
   <artifactId>simpleMavenDemo</artifactId>
   <version>0.0.1-SNAPSHOT</version>

   <properties>
       <java.source.version>1.7</java.source.version>
       <junit.version>4.8.2</junit.version>
   </properties>

   <dependencies>
       <dependency>
           <groupId>junit</groupId>
           <artifactId>junit</artifactId>
           <version>${junit.version}</version>
           <scope>test</scope>
       </dependency>
   </dependencies>

   <build>
       <plugins>
           <plugin>
               <artifactId>maven-compiler-plugin</artifactId>
               <version>2.3.1</version>
               <configuration>
                   <source>${java.source.version}</source>
                   <target>${java.source.version}</target>
               </configuration>
           </plugin>
       </plugins>
   </build>
</project>

In Gradle this would be:

apply plugin: 'java'
apply plugin: 'maven'

group = 'ch.bbv.gradledemo'
version = '0.0.1-SNAPSHOT'
//the default artifact id is the project name, which is per default the directory name of the project

project.ext.junitVersion='4.8.2'

sourceCompatibility = 1.7
targetCompatibility = 1.7

repositories {
   mavenCentral()
}

dependencies {
   testCompile 'junit:junit:'+junitVersion
}

The ‘maven’ plug-in allows you to install the artifact in your local Maven repository. Gradle’s DSL makes the build script much easier to read. Of course one could use polyglot Maven but that didn’t take off yet.

IDE integration

The first thing I tried was the Gradle plug-in called ‘eclipse’ (it’s a bit unlucky that everything is now called plug-in). This plug-in can generate eclipse configuration files with settings, project and classpath. This works quite well but you have to update and refresh the project yourself after changing the build.gradle file.

The opposite way around there are also plug-ins for eclipse. The first one is Groovy support so you can edit Groovy code in eclipse. The second one is the Gradle plug-in itself which manages the dependencies of your project, allows you to start Gradle tasks and more.

There is support for other IDEs as well. The current state of tooling can be found here: http://www.gradle.org/tooling

Documentation

Gradle comes with a comprehensive set of documentation including a user guide, reference material and even a book titled “Building and Testing with Gradle”. You can read the book online if you register on Gradleware’s web site. It’s a good read and covers all the stuff you need to get started with Gradle.

The user guide documents all the parts of Gradle and will be continuously extended as Gradle grows. The reference material is generated Java/Groovy doc for Gradle’s API and DSL.

Conclusion

I see three scenarios where Gradle can be a good candidate for your build system.

1. If you are currently using Ant and the build.xmls get too complicated to handle. With the task based build and the support for existing Ant tasks, Gradle support the migration from Ant.
2. You have trouble to get Maven to do what you want and maybe already started to write your own Maven plug-ins. Gradle supports the convention over configuration paradigm similar to Maven but can also be scripted with Groovy to do more powerful stuff.
3. You start a new project.

Gradle as a build system makes a very good impression to me. Hopefully there will be more plug-ins developed when more and more projects use it. I’ve seen that a Jacoco plug-in is under development for example. Gradle itself will continuously be extended and there is also a short- and long-term road-map available. It is licensed under the Apache License, Version 2.0 and is used by open source projects like Spring and Hibernate and also by commercial entities.

Even though it has a bit of a steep learning curve it is worth a closer look.

Thorsten Ruf und Roland Simon sind Experten für die Einführung, den Betrieb sowie individuelle Anpassungen und Migrationen des Team Foundation Servers.

Erschienen im windows.developer, 10.2012

Therefore, I wrote some NDepend queries that show us these misplaced or misnamed test classes.

Our coding guidelines

First, I have to state our coding guidelines regarding unit test structure and naming because the queries below are built against them.

Unit test class name

Each unit test class is named following this pattern:

[prefix]<name of class under test>Test

The prefix is optional and is used when multiple test classes exist for the same class under test. The prefix states which aspect of the class under test is tested in this specific test class. Then follows the name of the class under test and the suffix Test.

For example FooTest is the test class for class Foo and ExceptionCasesBarTest contains only the exception cases tests for class Bar.

Unit test is in the same namespace as the class under test, but in a dedicated test assembly

We put all our unit tests in assemblies named like the production assemblies with suffix .Test. That makes it easy to detect them and simplifies automatic builds.

Furthermore, a unit test class is always in the same namespace as the production class it is testing (we remove the .Test suffix in the default namespace of the test project).

Name of system under test

We always use the name testee for the instance that is under test. This helps to quickly grasp what is tested in a unit test.

[TestFixture]
public class FooTest
{
    private Foo testee;

    [SetUp]
    public void SetUp()
    {
        this.testee = new Foo();
    }

    [Test]
    public void DoesMagic()
    {
        string actual = this.testee.DoMagic();

        actual.Should().Be("magic");  // this is FluentAssertions, check it out!
    }
}

Finding misplaced unit tests

This is the query we use to find misplaced unit test. A misplaced unit test is not in the same namespace as the class it tests:

from p in Assemblies.WithNameWildcardMatchNotIn("*.Test").WithNameWildcardMatch("MyProject*").ChildTypes()
from t in Assemblies.WithNameWildcardMatch("*.Test").ChildTypes()
where t.IsUsing(p)
    && t.Name.EndsWith(p.Name + "Test")
    && t.ParentNamespace.Name != p.ParentNamespace.Name
select new { Class = p, Test = t, ClassNamespace = p.ParentNamespace, TestNamespace = t.ParentNamespace }

• select all types of our production assemblies (assemblies starting with our project name and not ending in Test)
• select all types of our unit test assemblies
• match test class and production class by checking whether the test class uses the production class and matches the name pattern (test class name ends with production class name + Test)
• take only the found pairs that don’t have the same namespace
• print the name of the class and test class and their namespaces

Finding misnamed unit tests (containing a testee):

This is the query to find unit test classes with an incorrect name, not following our name pattern:

from p in Assemblies.WithNameWildcardMatchNotIn("*.Test").WithNameWildcardMatch("MyProject*").ChildTypes()
from t in Assemblies.WithNameWildcardMatch("*.Test").ChildTypes()
where t.IsUsing(p)
    && t.Fields.Where(f => f.Name == "testee").Any()
    && t.Fields.Single(f => f.Name == "testee").FieldType == p
    && !t.Name.EndsWith(p.Name.Substring(0, p.Name.IndexOf("&& !t.IsGeneratedByCompiler
select new { Class = p, Test = t, t.ParentNamespace }

• select all types of our production assemblies (assemblies starting with our project name and not ending in Test)
• select all types of our unit test assemblies
• match test class and production class by checking whether the test class uses the production class and the type of the field testee
• take only class pairs that do not follow the naming convention
• skip generated classes

Finding unit tests missing TestFixture or not named with suffix Test:

This query finds unit test classes that miss either the TestFixture attribute or the suffix Test in the class name:

from t in Assemblies.WithNameWildcardMatch("*.Test").ChildTypes()
where
(
    t.HasAttribute("NUnit.Framework.TestFixtureAttribute")
    && !t.Name.EndsWith("Test")
) ||
(
    !t.HasAttribute("NUnit.Framework.TestFixtureAttribute")
    && t.Name.EndsWith("Test")
) ||
(
    t.InstanceMethods.Where(m => m.HasAttribute("NUnit.Framework.TestAttribute") || m.HasAttribute("NUnit.Framework.TestCaseAttribute")).Any()
    && !t.Name.EndsWith("Test")
)
orderby t.Name
select new { t, t.ParentNamespace }

• take all types from a test assembly that either have the TestFixture attribute or end with Test, but miss the other
• take all types from a test assembly that do have test methods but their name do not end in Test

Conclusions

NDepend queries can easily be used to spot unit test classes not complying with your coding conventions.

This is a great help after a refactoring sessions to check whether all parts are still in their correct place.

These queries can easily be changed to be used for other testing frameworks than NUnit or other coding conventions.

Let me know if you have some cool NDepend queries of your own.

You will learn how to use the Document Database RavenDB efficiently in your applications to save time and effort on communicating with database storage. During the course we will, as a team, build a practical application demonstrating all important data management patterns.

The course will be on October 1-2 in Lucerne an will be held in Englisch. Limited seats available only.

Register now!

Members of the .NET Usergroups Berne and Central Switzerland get a discount of 20%!

Der SQL Server bietet mit den Server-Side Traces ein leistungsfähiges Werkzeug, das sich für Produktivsysteme sehr gut eignet. Der Einsatz wird mit vier Hilfsprozeduren vereinfacht, die im Artikel vorgestellt werden.

Georg Lampart ist Senior Software Engineer bei der bbv Software Services AG mit Schwerpunkt SQL-Server-Datenbankentwicklung sowie der .NET-Softwareentwicklung in Bereich Businessapplikationen.

Erschienen im windows.developer, 8.2012

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <AvailableItemName Include="DynamicClientResource" />
  </ItemGroup>

  <PropertyGroup>
    <ClientResourceDir>$(OutDir)ClientResources\</ClientResourceDir>
  </PropertyGroup>

  <PropertyGroup>
        <BuildDependsOn>BuildClientResources;$(BuildDependsOn)</BuildDependsOn>
  </PropertyGroup>

  <Target Name="BuildClientResources" Outputs="%(DynamicClientResource.Identity)">
    <PropertyGroup>
      <ActualRelativeDir>%(DynamicClientResource.RelativeDir)</ActualRelativeDir>
      <RelativeNamespace>$(ActualRelativeDir.Replace("\","."))</RelativeNamespace>
    </PropertyGroup>
    <MakeDir Directories="$(ClientResourceDir)" Condition="Exists('%(DynamicClientResource.identity)')"/>
    <GenerateResource
    UseSourcePath="true"
    Sources="@(DynamicClientResource)"
    OutputResources="@(DynamicClientResource->'$(ClientResourceDir)$(RootNamespace).$(RelativeNamespace)%(filename).resources')">
    <Output
      TaskParameter="OutputResources"
      ItemName="Resources"/>
    </GenerateResource>
  </Target>
</Project>

If we include this custom build target into our build process, plugins can simply choose the “DynamicClientResource” as custom build action for all our resource files.

The result of this custom target is that all plugins and components which define resources will build the binary resources into the same directory under “ClientResources\”. If we use WCF services we can now leverage WCF streaming services to transfer the binary resources to the client. A basic service contract could look like the following:

    [ServiceContract(Namespace = "http://www.planetgeek.ch/resources")]
    public interface IDynamicResourceService
    {
        [OperationContract]
        IEnumerable<ResourceCatalogEntry> ResourceCatalog();

        [OperationContract]
        Stream Resource(ResourceCatalogEntry resource);
    }

    [DataContract(Namespace = "http://www.planetgeek.ch/resources")]
    public class ResourceCatalogEntry
    {
        [DataMember]
        public string FileName { get; set; }

        [DataMember]
        public string BaseName { get; set; }
    }

The service contract is split into two operations. One operation is to retrieve the whole resource catalog which contains information about the original file name and the base name of the resource. The second operation allows the client to stream a binary resource for a certain catalog entry. I think it is unnecessary to show how to implement the WCF service which fulfills this service contract. It is dead simple: Scan the client resource directory and provide resource catalog entries from the directory. For each acquired resource from the client open a read stream of the acquired catalog entry and return it to the client.

If we have this infrastructure in place the client can use a proxy to access the dynamic resource service. Upon start of the client all resources can be downloaded from the server and saved on the local disk. As you can imagine from the previous post we now need multiple file based resource managers on the client which are created dynamically from the downloaded binary resources from the server. In order to provide a unified interface for the client integration we need a simple resource manager decorator which handles this task for us.

	public class ResourceManagerDecorator : IResourceManager
    {
        private readonly Dictionary<string, ResourceManager> resourceManagers;

        public ResourceManagerDecorator()
        {
            this.resourceManagers = new Dictionary<string, ResourceManager>();
        }

        public void AddResourceFile(string baseName, string resourceDirectory)
        {
            if (!this.resourceManagers.ContainsKey(baseName))
            {
                ResourceManager resourceManager = ResourceManager.CreateFileBasedResourceManager(baseName, resourceDirectory, null);
                this.resourceManagers.Add(baseName, resourceManager);
            }
        }

        public bool IsValid(string resourceKey)
        {
			// Will be covered later
        }

        public string GetString(string resourceKey)
        {
			// Will be covered later
        }
    }

The decorator above simply creates a file based resource manager for each base name and hosts the created resource manager for future use. The next posts will cover how to build up dynamic resource keys so that they won’t collide on the client and how to hook up some magic with auto mapper to dynamically map resources with the resource manager decorator.

View and ViewModel communication

I was amazed by how easy it was to start using the Caliburn.Micro, given I had some support from a CM expert. The communication between the View and ViewModel is straightforward, easy to use and yet very powerful. CM wins over PRISM in this department. The ViewModel code is cleaner and I think that naming conventions are better than attributes. They require more knowledge about the framework but also encourage faster implementation.

• Caliburn.Micro

cal:Message.Attach="[Event Click] = [Action PortfolioClicked()]"

public bool CanPortfolioClicked { ... }
public void PortfolioClicked() { ... }

• PRISM

<Button Command="{Binding FinishCommand}"/>

this.FinishCommand = new DelegateCommand<object>(this.OnFinishCommand, this.OnCanFinishCommand);
private void OnFinishCommand(object obj) { ... }
private bool OnCanFinishCommand(object arg) { ... }

To choose or not to choose

After having such a blast I had to dig deeper. I even tried to abandon the “one framework to rule them all” way of thinking. Theoretically it is possible to combine those two Frameworks. Prism provides great support for the modular application development and offers UnityBootstrapper and MefBootstrapper. Ninject Bootstrapper is available on the Ninject forums but it’s not officially supported. So basically we could use PRISM to discover and load the modules and Caliburn.Micro for the V <-> VM interaction.
At some point I abandoned this idea since it’s just not needed:

• PRISM requires a View-First approach

1. The bootstrapper loads the modules.
2. The Views are located through the ViewExport Attributes
3. The view is instantiated and the VM is injected into the view

[ViewExport(RegionName = RegionNames.MainRegion)]
[PartCreationPolicy(CreationPolicy.NonShared)]
public partial class WatchListView : UserControl
{
     public WatchListView (WatchListViewModel watchListViewModel)
     {
          this.DataContext = watchListViewModel;
     }
}

• Caliburn.Micro promotes a ViewModel-First approach

1. The bootstrapper loads the modules
2. IOC container finds the ViewModels that are injected into the ShellVM.
3. Views are resolved by the ViewModelBinder

If the ViewModel-First approach is chosen, then a big part of PRISM is not required anymore and vice versa. Caliburn.Micro also supports View-First approach, which is not recommended. Even more Prism features would become redundant when using the Caliburn.Micro with View-First approach.

EventAggregation

Event aggregation is another important feature provided by both frameworks. The purpose of the Event Aggregator is to simplify event registration by channeling events from multiple objects into a single object. The usage feature is pretty much identical in both frameworks.

• PRISM

In PRISM, an event is declared by inheriting from a CompositePresentationEvent where T is the message payload.
Subscribing has up to five parameters including whether to hold a strong or weak reference to the subscriber, which thread to call subscribers on, a filter to determine if the subscriber gets the event, and the delegate to invoke.
The defaults work for most situations.

public class FooEvent : CompositePresentationEvent<FooEventArgs> { }
myEventAggregator.GetEvent<FooEvent>().Publish(fooEventArgs);
myEventAggregator.GetEvent<FooEvent>().Subscribe(OnFoo);

• Caliburn.Micro

Event Aggregation in Caliburn Micro is simple.  In Caliburn Micro, events are plain old CLR objects (poCo).  The event argument payload, if needed, is declared in the event as one or more simple properties. Somehow the way the event aggregation works reminds me of EvenBroker in APPcelerate.
This IHandle approach makes explicit and clear at a glance the relationship between interested subscribers and their subscribed events.
Caliburn.Micro isn’t as powerful as PRISM. Yet it prevents you from creating bugs that are very hard to pinpoint. It holds weak references in the event aggregator and executes events on the UI thread.

public class FooEvent { public string myProp; }
public class Foo : IHandle<FooEvent>
    {
        private IEventAggregator myEventAggregator;

        public Foo()
        {
            myEventAggregator.Subscribe(this);
        }

        public void Handle(FooEvent message)
        {

        }
    }
myEventAggregator.Publish<FooEvent>(new FooEvent());

Navigation

The basic navigation features are supported by both frameworks. After spending some hours analyzing the navigation features in Caliburn.Micro I have to say that PRISM offers more functionality. I wasn’t able to find support for the following features in Caliburn.Micro:

1. State-Based Navigation – Used to display the same data with different formats and styles.
2. View lifetime management.
3. Navigation history
4. Exception handling to prevent application crashes on navigation exceptions. (For example if the view is missing or view model produces an exception during the navigation)

When to use PRISM or Caliburn.Micro?

I’ve started comparing those two frameworks to find a better one. Right now I think that they’re both good just for a different type of application. If I had to develop an application with a lot of different teams working on the same application I would still pick PRISM. Support for the development of modular applications and navigation support wins here. For the smaller projects, which are being developed by a single team, I would pick Caliburn.Micro, especially if the team consists of developers that are inexperienced with both frameworks. Caliburn.Micro has everything that should be supported by a MVVM framework. On top of that less functionality also means lower complexity, resulting in lower probability of misuse or bugs.

Further Informations

In case you’d like more in depth information, here are some links that proved to be very informative:

1. http://msdn.microsoft.com/en-us/library/gg430861(v=pandp.40).aspx#sec1 - PRISM Navigation
2. http://devlicio.us/blogs/rob_eisenberg/archive/2010/07/06/caliburn-micro-soup-to-nuts-pt-1-configuration-actions-and-conventions.aspx - Everything you could possibly want to know about Caliburn.Micro. A series written by Rob Eisenberg.

I would like to thank Daniel Marbach for his invaluable help. He supported me on the technical part considering Caliburn.Micro and was kind enough to review the posting.

In languages like C and C++, memory management was left to the responsibility of the software engineer. Modern C++ designs make heavy use of dynamic memory. (e.g. Inversion of control, dependency injection, factories, collections of objects, design for testability, event passing with objects, etc.)
This is a standard practice in desktop applications, where memory is freely available and latency not an issue.

On embedded and real time systems, the situation is different:
Dynamic allocation of memory may be non-deterministic, depending on the underlying operating system. Fragmentation of the dynamic memory pool can lead to a slower system responsibility over time or even worse to “out of memory” exceptions, even if there is enough memory available.

A conservative approach in designing real-time systems is not to use dynamic memory at all. But there are also other possibilities to implement such systems.

C++ Memory Spaces

First let us have a look at the memory usage in C++:
In C++ memory can be regarded as being divided into three parts. There is static memory, automatic variables and dynamic memory.

• Static memory allocation refers to the process of allocating memory at compile-time before the associated program is executed. The actual allocation of addresses to variables is performed by the embedded software development toolkit.
• All variables declared within a block of code are automatic by default. This means they are allocated and de-allocated automatically when the program flow enters and leaves the variable’s scope. Automatic variables are stored on the stack.
• Dynamic memory is allocated from the heap. The two key dynamic memory functions are new and delete. The allocation and deletion of memory are non-deterministic operations on most operating systems. Depending on the dynamic memory allocation strategy we may observe a degradation of performance over time due to fragmentation issues.

Static memory should not cause any run-time problems. Automatic variables shouldn’t be a problem either, unless the stack size is too small and a stack overflow occurs.

Dynamic memory however is a big issue. One approach to manage dynamic memory on a real-time system is to use a fixed-size pre-allocated memory block, a memory pool.

Memory pooling

A Memory pool allows dynamic memory allocation comparable to malloc or C++’s operator new. But almost all implementations suffer from fragmentation because of variable block sizes. The use of memory pools has been considered a source of in-determinism in the real-time domain, due to the unconstrained response time of dynamic storage allocation algorithms and the fragmentation problem.

However there are some memory pool implementations that are capable to circumvent these issues.
One of those is TLSF. (http://www.gii.upv.es/tlsf/ )

Two-Level Segregated Fit memory allocator (TLSF)

TLSF is a general purpose dynamic memory allocator specifically designed to meet real-time requirements. TLSF implements a two level mechanism:

The first level uses an array which divides free blocks in classes, that are a power of two apart (8, 16, 32, 64, etc.).  The second level subdivides each first-level class in a linear manner. The second level contains an associate bitmap used to mark which lists are empty and which ones contain a free block.

The advantages of this approach are:

• Bounded Response Time: TLSF has a constant cost for memory allocation and de-allocation of O(1).
• Fast: TLSF executes a maximum of 168 processor instructions in a x86 architecture. It can be slightly lower or higher, depending on the compiler and optimization.
• Efficient Memory Use: The maximum fragmentation measured is lower than 25%.

(For more documentation on TLSF see also: http://www.gii.upv.es/tlsf/main/pubs/)

Example in c++

TLSF uses a plain c interface style api. In order to use TLSF from c++ one has to overload the new and delete operators.
Here are the functions that have to be implemented:

#ifndef WRAPPER_H
#define WRAPPER_H
#include
void* operator new(std::size_t p_RequestedSize) throw (std::bad_alloc);
void operator delete(void* p_Address) throw();

void* operator new[](std::size_t p_RequestedSize) throw (std::bad_alloc);
void operator delete[](void* p_Address) throw();

void* operator new(std::size_t p_RequestedSize, const std::nothrow_t& pc_Exception) throw();
void operator delete(void* p_Address, const std::nothrow_t& pc_Exception) throw();

void* operator new[](std::size_t p_RequestedSize, const std::nothrow_t& pc_Exception) throw();
void operator delete[](void* p_Address, const std::nothrow_t& pc_Exception) throw();
#endif // WRAPPER_H

And the implementation:

#include "wrapper.h"
extern "C"{
#include
}
void* operator new(std::size_t p_RequestedSize) throw (std::bad_alloc){
   void* const result = ::tlsf_malloc(p_RequestedSize);
   if (0 == result) {// throw exception }
   return result;
}

void operator delete(void* p_Address) throw(){
   return ::tlsf_free(p_Address);
}
// other operators follow the same scheme...

Now let’s have a look at a little demo program:

#include
#include
#include
extern "C"
{
#include
}
#include "wrapper.h" // This redefines new and delete
// Test class
class DummyClass
{
public:
   DummyClass(){ s_counter++;};
   virtual ~DummyClass(){s_counter--;};
   static unsigned int s_counter;
protected:
   unsigned short m_pBuffer [100];
};
unsigned int DummyClass::s_counter = 0;
//-------------------------------------
int main()
{
    int mPoolSize = 65536;
    void* mPoolbuffer = ::malloc(mPoolSize);

    // create memory pool
    ::memset(mPoolbuffer, 0, mPoolSize);
    ::init_memory_pool(mPoolSize, mPoolbuffer); // TLSF function

    // statistics
    size_t  used = get_used_size(mPoolbuffer); // TLSF function
    std::cout << "Before new DummyClass....:" << used << std::endl;

    // usage of operator new()
    DummyClass* pClass = new DummyClass();

    // statistics
    used = get_used_size (mPoolbuffer); // TLSF function
    std::cout << "After new DummyClass.....:" << used << std::endl;

    // usage of operator delete()
    delete pClass;

    // statistics
    used = get_used_size(mPoolbuffer); // TLSF function
    std::cout << "After delete pClass......:" << used << std::endl;

    // usage of operator new[]()
    char* pCharArray = new char[245];

    // statistics
    used = get_used_size(mPoolbuffer); // TLSF function
    std::cout << "After new char[245]......:" << used << std::endl;

    // usage of operator delete[]()
    delete [] pCharArray;

    // statistics
    used = get_used_size(mPoolbuffer); // TLSF function
    std::cout << "After delete [] pChar....:" << used << std::endl;

    // delete memory pool
    ::destroy_memory_pool(mPoolbuffer); // TLSF function
    return 0;
}

(* To enable statistics enable TLSF_STATISTIC (1) in tlsf.cpp )

And the output is:

Before new DummyClass....:6384
After new DummyClass.....:6608
After delete pClass......:6384
After new char[245]......:6656
After delete [] pChar....:6384

Summary

TLSF enables you to predictably use dynamic memory in real-time applications. But the usage of dynamic memory will always increase the complexity of a real-time system. Therefore its use should be restricted to cases where it is really needed, for example in message communication related operations. Because don’t forget, with dynamic memory allocation, memory leaks can plague the system for a long time. (see also C++ Memory error detection on a Linux platform)