Im zweiten Teil der unbestimmt langen Reihe Multithreading in .NET befasse ich mich mit der Klasse System.Threading.Monitor.

System.Threading.Monitor

Der Monitor ist das Objekt, was sich bei genauerer Betrachtung hinter einem lock-Statement verbirgt. Die Details dazu können im ersten Teil nachgelesen werden. Die Verwendung ist der eines lock-Statements sehr ähnlich. Man verwendet den Monitor stets in Verbindung mit einem Objekt, welches verriegelt werden soll. Der daraus resultierende IL-Code unterscheidet sich ebenfalls nicht von dem eines lock-Statements.

private void monitorNotationExample( object lockObject )
{
    Monitor.Enter( lockObject );

    //Critical Section: Do something

    Monitor.Exit( lockObject );
}

Nach der Critical Section muss allerdings im Gegensatz zum lock-Statement die Verriegelung explizit wieder freigegeben werden. Dies macht den Monitor etwas fehleranfälliger als das lock-Statement. Er hat allerdings auch einige ganz entscheidende Vorteile.

Vorteile der Klasse Monitor gegenüber lock

Die Klasse Monitor stellt neben der Funktion Enter noch die Funktion TryEnter bereit, um eine exklusive Sperre für eine Critical Section zu bekommen. Die Funktion TryEnter ist doppelt überladen und liefert jeweils einen Booleschen Wert zurück.

Monitor.TryEnter

Der Aufruf der Funktion Monitor.TryEnter(Object) versucht, eine exklusive Sperre auf das übergebene Objekt zu erlangen. Schlägt dies fehl, weil bereits ein anderer Thread eine Sperre auf dieses Objekt hält, liefert die Funktion ein false zurück. Konnte die Sperre erlangt werden, wird true zurückgegeben.

Monitor.TryEnter (Object, Int32)

Die erste Überladung der Funktion mit dem zusätzlichen Parameter vom Typ Int32 dient dazu, einen Timeout anzugeben. Dieser Timeout wird Anzahl der Millisekunden übergeben, die maximal versucht werden soll, eine exklusive Sperre für das Objekt zu erlangen. Wird zu einem beliebigen Zeitpunkt innerhalb der Zeitspanne die Sperre erlangt, gibt der Aufruf true zurück. Wird der Timeout erreicht, kehrt der Aufruf mit false zurück. Dieser Aufruf ermöglicht es also, eine bestimmte Zeit auf eine Sperre zu warten. Der Rückgabewert muss also in jedem Fall ausgewertet werden. Außerdem muss man bei der Verwendung der Funktion Monitor.TryEnter (Object, Int32) darauf achten, dass eine geeignete Strategie vorhanden ist für den Fall, dass keine Sperre registriert werden konnte.

Monitor.TryEnter (Object, TimeSpan)

Die zweite Überladung verlangt als zweiten Parameter keinen Int32, der die Anzahl der Millisekunden für den Timeout angibt, sondern eine Zeitspanne vom Typ System.TimeSpan. Mit dieser zweiten Überladung ist es also möglich, die ersten beiden Funktionsaufrufe nachzubilden. Entweder wird als Zeitspanne wirklich eine Zeitspanne übergeben, was der ersten Überladung entspräche, oder es wird Timeout.Infinite übergeben, was dem Aufruf der Funktion Monitor.TryEnter(Object) entspräche.

Einige Beispiele

Um die Funktionsweise der einzelnen Methoden der Monitor-Klasse zu verdeutlichen, werde ich einige Beispiele anführen. Beginnen wir mit einfacheren Verwendung des Monitors. Wir nehmen einen Konsolenanwendung und erweitern diese mit der Klasse AsyncTest. In dieser Klasse sind zwei Methoden enthalten, Sync1() und Sync2(). Beide Methoden greifen auf dasselbe lock-Objekt zu. nämlich lock1.

class Program
{
    static void Main( string[] args )
    {
        AsyncTest test = new AsyncTest( );
        Thread thread1 = new Thread( new ThreadStart( test.Sync1 ) );
        Thread thread2 = new Thread( new ThreadStart( test.Sync2 ) );

        thread1.Start( );
        thread2.Start( );
        Console.ReadLine( );
    }
}

public class AsyncTest
{
    private object lock1 = new object( );

    public void Sync1( )
    {
        Monitor.Enter(lock1);
        for ( int i = 1; i <= 20; i++ )
        {
            Console.Write( "1 {0}|", i );
            Thread.Sleep( 20 );
        }
        Monitor.Exit( lock1 );
    }

    public void Sync2( )
    {
        Monitor.Enter( lock1 );
        for ( int i = 1; i <= 20; i++ )
        {
            Console.Write( "2 {0}|", i );
            Thread.Sleep( 20 );
        }
        Monitor.Exit( lock1 );
    }
}

Die Ausgabe der beiden Threads erfolgt sequenziell, wie bereits im ersten Teil erklärt.

Schauen wir uns im nächsten Beispiel die Funktionsweise der Methode TryEnter an. Thread 2 in der Main-Routine führt nun die Methode Sync3 in der Klasse AsyncTest aus. Diese versucht über den Aufruf von Monitor.TryEnter(lock1) eine Sperre auf das Objekt zu bekommen.

class Program
{
     static void Main( string[] args )
     {
         AsyncTest test = new AsyncTest( );
         Thread thread1 = new Thread( new ThreadStart( test.Sync1 ) );
         Thread thread2 = new Thread( new ThreadStart( test.Sync3 ) );

         thread1.Start( );
         thread2.Start( );
         Console.ReadLine( );
     }
}

public class AsyncTest
{
    private object lock1 = new object( );

    public void Sync1( )
    {
        Monitor.Enter(lock1);
        for ( int i = 1; i <= 20; i++ )
        {
            Console.Write( "1 {0}|", i );
            Thread.Sleep( 20 );
        }
        Monitor.Exit( lock1 );
    }


    public void Sync3( )
    {
        if ( Monitor.TryEnter( lock1 ) )
        {
            Console.WriteLine( Environment.NewLine + "Lock achieved." );
            Monitor.Exit( lock1 );
        }
        else
        {
            Console.WriteLine( Environment.NewLine + "Lock cannot be achieved." );
        }
    }
}

Ergibt:



Die Ausgabe zu diesem Beispiel entspricht der Beschreibung der Methode Monitor.TryEnter(). Es wird versucht, eine Sperre auf das übergebene Objekt zu registrieren. Schlägt dies fehl, kehrt die Methode mit false zurück. Hätte eine Sperre registriert werden können, wäre true zurückgegeben worden.
Betrachten wir das Verhalten der Methode Sync3() nun einmal mit Übergabe eines Timeouts. Dieser soll 100 Millisekunden lang sein. Die neue Methode nennen wir Sync4() und verdrahten sie in der Main-Methode auf den zweiten Thread:

public void Sync4( )
{
    if ( Monitor.TryEnter( lock1, 100 ) )
    {
        Console.WriteLine( Environment.NewLine + "Lock achieved." );
        Monitor.Exit( lock1 );

    }
    else
    {
        Console.WriteLine( Environment.NewLine + "Lock cannot be achieved." );
    }
}

Wie man sehen kann, kehrt die Methode Sync4 etwas später zurück als Sync3 im vorigen Beispiel, kann jedoch immer noch keine Sperre registrieren. Betrachten wir die Funktion Sync1 genauer, wird auch schnell klar, warum. Sie dauert bei 20 Schleifendurchläufen mit jeweils einem Sleep von 20 Millisekunden mindestens 400 Millisekunden.
Setzen wir nun also den Timeout in Sync4 auf 1000 Millisekunden.



Wie man sehen kann, war der Timeout nun so lang, dass Sync1 vollständig abgearbeitet und die Sperre freigegeben werden konnte, bevor der Timeout abgelaufen war. Der zweite Thread konnte seine Sperre erfolgreich registrieren.

Platzierung der lock-Freigabe Monitor.Exit()

Wie man an Hand der Funktionen Sync3 und Sync4 erkennen kann, habe ich die Freigabe der Sperre nicht an das Ende der Funktion gestellt, sondern an das Ende des Zweigs, der bei erfolgreicher Registrierung der Sperre angesprungen wird. Wird nämlich die Funktion Exit(object) auf ein Objekt aufgerufen, für welches der aufrufende Thread keine Sperre registriert hat, bekommt man von der Runtime eine SynchronizationLockException vor den Bug geknallt, die man dann behandeln darf.
 


Um dies zu vermeiden (und um logischeren Code zu schreiben) sollte man allerdings den von mir gewählten Weg gehen und die Sperre nur dann freigeben, wenn sie auch wirklich registriert wurde. Außerdem sollte man die Freigabe der Sperre in einem finally-Block notieren, um auf alles vorbereitet zu sein. Auch wenn irgendwo innerhalb der Critical Section eine Exception geworfen wird, wird so wenigstens die Sperre freigegeben und die Chance erhöht, dass sich die Anwendung nicht in einem "Deadlock "aufhängt".
Die richtige Notation für den Monitor wäre also:

public void Sync6( )
{
    if ( Monitor.TryEnter( lock1, 1000 ) )
    {
        try
        {
            //Critical section
        }
        finally
        {
            Monitor.Exit( lock1 );
        }
    }
    else
    {
        //else-Fall behandeln
    }
}

Und wem bei der Betrachtung dieser Methode das C# Keyword using in den Kopf kommt, der ist ganz nah bei dem, was sich die .NET-Entwickler gedacht haben. Ändert man den Timeout von 1000 Millisekunden auf Timeout.Infinite und lässt den else-Zweig weg, entspricht diese Methode dem lock-Statement. Womit nun der Unterschied zwischen den drei Methoden Enter, TryEnter und Exit des Monitors sowie dem lock-Statement hinreichend beschrieben sein sollte.

Fassen wir noch einmal zusammen:

• Das lock-Statement wartet, bis es eine Sperre registrieren konnte. Die Freigabe der Sperre erfolg in einem "finally"-Block (die geschweifte Klammer zu des lock-Blocks).
• Enter versucht eine Sperre zu registrieren und kehrt sofort zurück. Entweder ist die Sperre registriert (Rückgabe true) oder eben nicht (Rückgabe false). Auf jeden Fall muss sich der Programmierer Gedanken im das Exception Handling machen.
• TryEnter erweitert Enter um die Möglichkeit, einen bestimmten Zeitraum auf eine Sperre zu warten. Entweder wird die Sperre in diesem Zeitraum registriert (Rückgabe true) oder die Zeit läuft ab (Rückgabe false). Auch hier muss der Programmierer sich um das Exception Handling selbst kümmern.
  

Im nächsten Teil werde ich die restlichen Funktionen der Klasse Monitor beleuchten: Monitor.Wait(), Monitor.Pulse() und Monitor.PulseAll(). Bis dahin freue ich mich auf Feedback und/oder Anregungen.

During my nightly coding session working on my gps class library for my smart phone I started to use the xml decomentation tags see and seealso. Later on after the "nightly build" I had several warnings that the compiler could not resolve the types provided inside these tags. But thanks to Alan Dean and his great artivle about XML documentation in C# my usual sleep amount wont be decreased as much as I feared 10 minutes before.

Last friday, June 6th, the Microsoft .Net Microframework Team announced a new version 3.0 of the .Net Micro framework. Several cool features are supported, for example a file system, toch screen support and the development environment was changed to VS2008. Have a look at the complete list of new features. Now I hope that Device Solutions will update the Tahoe firmware as soon as possible so that I can profit from the new features.

Bereits seit einiger Zeit sind Multi-Core-Prozessoren für den normalen Konsumenten erschwinglich. In Servern werden bereits seit einigen Jahren Multiprozessorsysteme eingesetzt. Jedoch kommt mir immer wieder Code unter, der sich strikt an einen Kern bindet, weil keine Operation asynchron ausgeführt wird. Ich persönlich vertrete die Meinung, dass  allein aus Gründen der User Experience mehrere Threads eingesetzt werden sollen. Welcher Benutzer sieht es schon gern, wenn er auf einen Button drückt, und die Anwendung für einige Sekunden zu einer weißen Fläche wird? In Gesprächen mit Entwicklern höre ich jedoch immer wieder das Argument, dass Multithread-Programmierung ja so kompliziert sei und man es lieber nicht verwendet, um keine Fehler zu machen. Denn das Debugging von Multithreaded-Code ist nicht so trivial wie bei Singlethreaded-Code. Daher möchte ich in einer unbestimmt langen Reihe einige Aspekte des Multithreading beleuchten.

lock

Beginnen möchte ich mit dem C#-Keyword lock. Das lock-Statement ist nur in C# verfügbar. Es wird ähnlich dem using-Statement verwendet:

lock(obj)
{
    //Do something synchronized
}

lock wird also auf ein Objekt aufgerufen. Der Code innerhalb des Blocks wird nur aufgeführt, wenn das der lock-Aufruf zurückgekehrt ist. Es ist also sichergestellt, dass der Code innerhalb des Blocks immer nur von einem Thread ausgeführt wird. Der Blockinhalt wird auch Critical Section genannt.

Wie verwendet man lock?

Die Syntax für die Nutzung von lock ist denkbar einfach. Allerdings sind einige Einschränkungen bei der Verwendung zu beachten.

Reference-Type

lock kann nur auf Reference-Types aufgerufen werden. Dies hängt damit zusammen, dass lock eigentlich eine Maskierung für

Monitor.Enter(lockobject);

ist.

Auf welches Objekt soll das lock aufgerufen werden?

Oft sieht man Konstrukte wie

lock(this){ }

Diese verletzen jedoch oft die Design Guidelines für Multithreadprogrammierung. Und zwar in den folgenden Fällen:

• lock(this){ } kann zu einem Problem werden, wenn die Instanz des Objekts public ist, also öffentliche Zugriffe erlaubt.

• lock(typeof(MyType)){ } ist ebenfalls problematisch, wenn MyType öffentlich zugänglich ist.

• lock("mylock") { } bedeutet, dass alle lock-Statements, die so geschrieben werden,
  dasselbe Lock-Objekt benutzen, da es sich um einen String handelt.

lock sollte also immer auf dedizierte private Objekte aufgerufen werden. Soll eine Critical Section über alle Instanzen eines Objekts geschützt sein, definiert man das lock-Objekt als static.

private static object lockObj = new object();

private void foo()
{
    lock(lockObj)
    {
        //Critical section
    }
}

Was passiert bei einem lock?

Nehmen wir eine Methode einer Windows-Forms-Anwendung. Auf dem Formular ist ein Button button1 platziert. Klickt man diesen an, soll sich der Text des Formulars nach „LOCKED“ ändern. Es ergibt sich folgende Funktion:

private void button1_Click(object sender, EventArgs e)
{
    lock (this.lockObject)
    {
        this.Text = "LOCKED";
    }
}

Was macht der Compiler aus dieser Funktion? Schauen wir uns die erzeugte Intermediate Language an:

.method private hidebysig instance void button1_Click(object sender, class [mscorlib]System.EventArgs e) cil managed
{
    .maxstack 2
    .locals init (
        [0] object CS$2$0000)
    L_0000: nop 
    L_0001: ldarg.0 
    L_0002: ldfld object lock1.Form1::lockObject
    L_0007: dup 
    L_0008: stloc.0 
    L_0009: call void [mscorlib]System.Threading.Monitor::Enter(object)
    L_000e: nop 
    L_000f: nop 
    L_0010: ldarg.0 
    L_0011: ldstr "LOCKED"
    L_0016: callvirt instance void [System.Windows.Forms]System.Windows.Forms.Control::set_Text(string)
    L_001b: nop 
    L_001c: nop 
    L_001d: leave.s L_0027
    L_001f: ldloc.0 
    L_0020: call void [mscorlib]System.Threading.Monitor::Exit(object)
    L_0025: nop 
    L_0026: endfinally 
    L_0027: nop 
    L_0028: ret 
    .try L_000f to L_001f finally handler L_001f to L_0027
}

Wie man sieht, wird das lock-Statement zu einem System.Threading.Monitor.Enter(lockObject) aufgelöst. Der entsprechende Aufruf der Methode System.Threading.Monitor.Exit(lockObject) wird in einen finally-Block eingefasst. Es kann also innerhalb der Critical section passieren, was will, der Monitor wird  freigegeben. Dies ist einer der großen Vorteile des lock-Statements. Der Entwickler muss sich nur sehr wenige Gedanken um die korrekte Freigabe des Monitors machen, da dies der Compiler für ihn erledigt.

Allerdings verbirgt sich hier auch einer der Nachteile des lock-Statements. Der Compiler löst das lock-Statement in ein Monitor.Enter(lockObject) auf. Das kann unter Umständen dazu führen, dass der Aufruf nie zurückkehrt, man also in eine Deadlock-Situation gerät. Um dies zu vermeiden, verwendet man besser Monitor.TryEnter(object, TimeSpan). TryEnter versucht für die angegebene Zeitspanne ein lock auf das Objekt zu erlangen. Schlägt dies fehl, kehrt die Methode mit false zurück. Der Nachteil dieses Aufrufs ist jedoch, dass der Entwickler sich nun selbst um das Fehlerhandling kümmern muss. Folgender Codeblock kann also statt des lock-Statements verwendet werden:

if ( !Monitor.TryEnter( lock2, TimeSpan.FromSeconds( 1 ) ) )
{
    throw new ApplicationException( "Unable to claim lock on object {0}", lock2.ToString() );
}
try
{
    //Critical section
}
finally
{
    Monitor.Exit( lock2 );
}

In diesem Fall liegt die Freigabe des Monitors jedoch ganz auf Seiten des Entwicklers. Außerdem muss er sich Gedanken darüber machen, wie die Applikation darauf reagiert, wenn der Monitor nicht in der vorgegebenen Zeitspanne erlangt werden kann. Deadlocks sind so jedoch ausgeschlossen.

Einige Beispiele

Zuerst schauen wir uns an, wie sich zwei Methoden verhalten, die von unterschiedlichen Threads aus aufgerufen werden. Eine dieser Methoden ist durch ein lock verriegelt:

class Program
 {
     static void Main( string[] args )
     {
         AsyncTest test = new AsyncTest( );
         Thread thread1 = new Thread(new ThreadStart(test.SyncLock1));
         Thread thread2 = new Thread( new ThreadStart( test.UnsyncLock1 ) );

         thread1.Start( );
         thread2.Start( );
         Console.ReadLine( );
     }
 }

 public class AsyncTest
 {
     private object lock1 = new object( );

     public void SyncLock1( )
     {
         lock ( lock1 )
         {
             for ( int i = 1; i <= 20; i++ )
             {
                 Console.Write( "SyncLock1 {0}|", i );
                 Thread.Sleep( 20 );
             }
         }
     }

     public void UnsyncLock1( )
     {
         for ( int i = 1; i <= 20; i++ )
         {
             Console.Write( "UnsyncLock1 {0}|", i );
             Thread.Sleep( 20 );
         }
     }
 }

Auf der Konsole wird folgendes ausgegeben:

Man kann also sehen, dass die beiden Threads sich nicht von dem lock des einen beeindrucken lassen. Warum auch, schließlich wird keiner durch das lock tangiert.

Ändern wir das Programm etwas ab und fügen eine Methode hinzu die ebenfalls durch ein lock verriegelt ist:

class Program
{
    static void Main( string[] args )
    {
        AsyncTest test = new AsyncTest( );
        Thread thread1 = new Thread(new ThreadStart(test.SyncLock1));
        Thread thread2 = new Thread( new ThreadStart(test.SyncLock2 ) );

        thread1.Start( );
        thread2.Start( );
        Console.ReadLine( );
    }
}

public class AsyncTest
{
    private object lock1 = new object( );
    private object lock2 = new object( );

    public void SyncLock1( )
    {
        lock ( lock1 )
        {
            for ( int i = 1; i <= 20; i++ )
            {
                Console.Write( "SyncLock1 {0}|", i );
                Thread.Sleep( 20 );
            }
        }
    }

    public void SyncLock2( )
    {
        lock ( lock2 )
        {
            for ( int i = 1; i <= 20; i++ )
            {
                Console.Write( "SyncLock2 {0}|", i );
                Thread.Sleep( 20 );
            }
        }
    }
}

Die Konsolenausgabe gleicht der des ersten Beispiels:

Denn auch hier ist es so, dass beide Methoden unabhängige Locks verwenden, sodass keine die andere beeinflusst.

Verriegeln wir nun die zwei Methoden mit demselben lock-Objekt:

class Program
{
    static void Main( string[] args )
    {
        AsyncTest test = new AsyncTest( );
        Thread thread1 = new Thread(new ThreadStart(test.SyncLock1));
        Thread thread2 = new Thread( new ThreadStart( test.SyncLock3 ) );

        thread1.Start( );
        thread2.Start( );
        Console.ReadLine( );
    }
}

public class AsyncTest
{
    private object lock1 = new object( );
    
    public void SyncLock1( )
    {
        lock ( lock1 )
        {
            for ( int i = 1; i <= 20; i++ )
            {
                Console.Write( "SyncLock1 {0}|", i );
                Thread.Sleep( 20 );
            }
        }
    }

    public void SyncLock3( )
    {
        lock ( lock1 )
        {
            for ( int i = 1; i <= 20; i++ )
            {
                Console.Write( "SyncLock3 {0}|", i );
                Thread.Sleep( 20 );
            }
        }
    }
}

Die Methoden werden nun nacheinander abgearbeitet:

Was bedeutet dies nun?

Auf ein Objekt kann nur ein lock (intern ja eigentlich ein Monitor) vergeben werden. Verwenden verschiedene Methoden verschiedene lock-Objekte, beeinflussen sich diese Methoden nicht. Verwenden sie das gleiche lock-Objekt, warten alle Threads, die die Critical Section betreten wollen, bis sie Einer nach dem Anderen das lock auf das Objekt erhalten. Damit einher geht natürlich die Notwendigkeit, dass ein Thread, der eine Critical Section betritt, beim Verlassen dieser das Lock-Objekt wieder freigibt, sodass ein anderer Thread die Critical Section betreten kann.

Links

• lock Statement (C# Reference)

• Monitor.TryEnter, lock, using, and Deadlock

• Thread Synchronization (C# Programming Guide)

• Multi-threading in .NET: Introduction and suggestions

Ausblick

Im nächsten Teil werde ich das Synchronisationsobjekt Monitor beleuchten. Bis dahin freue ich mich über Rückmeldungen zu diesem Teil.

Robert Mühsig hat auf dem Code-Inside Blog einen wunderbaren Post über den Einstieg in Unit Testing mit Visual Studio 2008 geschrieben. Ich persönlich bin bisher ebenfalls von den von Robert angeführten Gründen noch kein Fan von Unit Testing, weiß jedoch, dass es die Qualität von Software verbessert (gegenüber keinen Unit Tests). Angetriggert durch seinen Post werde ich mich nun auch einmal mit dem der Thematik auseinander setzen. Der Einstieg scheint nicht so schwer zu sein (dank der mittlerweile hervorragenden Integration in Visual Studio) und verlieren kann man auch nichts.

Der Bielefelder Verein FoeBuD (Verein zur Förderung des öffentlichen bewegten und unbewegten Datenverkehrs e.V.) hat nach jahrelanger erfolgreicher Arbeit sein Einzugsgebiet für aktive Mitstreiter vergrößert. War bisher Bielefeld der Ort, an dem sich die Mitglieder trafen, so gibt es nun ein Konzept für FoeBud-Treffs (man könnte es mit den Chaos-Treffs des CCC vergleichen, wenn es auch nicht das gleiche ist). Der erste FoeBud-Treff wurde nun in Siegen gegründet, und ich bin dabei. Momentan noch nicht als Mitglied im FoeBuD, aber das wird sich in näherer Zukunft ändern.

Wer Interesse an der Mitarbeit hat oder sich einfach über Themen wie Datenschutz, Videoüberwachung oder ähnliches informieren möchte, ist herzlich eingeladen, uns bei einem Treffen zu besuchen oder uns auf anderem Wege zu kontaktieren. Regelmäßiger Treffpunkt ist das 7inch in der Siegener Oberstadt. Die Treffen finden jeweils am zweiten und vierten Mittwoch des Monats statt.

Ich hoffe, dass mein Handyvertrag jetzt schneller ausläuft und mein Provider des Vertrauens das kleine Juwel in sein Portfolio übernimmt. Man sehe uns staune... das iPhone ist ja wohl ein Witz dagegen. Darauf läuft ja noch nicht einmal ein .NET Framework ;)

The project I'm currently working on is an embedded device without any graphical interface capability. The only ways to get some information out is the NIC or a serial port. There is also a CAN-Bus interface, but as far as my company developed the device it is better to not base our debugging capabilities on a potentially buggy part of the system. Out first debug out was implemented as a serial output tracer. As the day comes closer that out hardware prototypes will arrive, the higher the need to port the tracing over to the NIC as far as the final hardware won't have a serial port on it.
So last week the network tracer was check in into source control. Now, how to read these information?
Windows ships with Hyper Terminal. But this isn't very comfortable and you manually have to reestablish a lost connection. In my today's lunch break I wrote a small powershell script that listens to the network socket. At the moment I'm porting it to C# to add some more features.

But here is the first part, a small and simple powershell script to listen to a network socket. But please let me clarify that this is code snippet is NOT the way code. It was a fast hack to get it running. There is no error handling and ressources are not freed gracefully as it has to be terminated with ctrl + c. In clear words: This is a sample on how to receive data from a network socket.

$socket = new-object System.Net.Sockets.TcpClient("172.16.170.123", 9950)
if($socket -eq $null) { return; }
$stream = $socket.GetStream()
$buffer = new-object System.Byte[] $socket.ReceiveBufferSize
$encoding = new-object System.Text.AsciiEncoding

while($true)
{
   if($stream.DataAvailable)
   {
      $read = $stream.Read($buffer, 0, $socket.ReceiveBufferSize)  
      write-host -n ($encoding.GetString($buffer, 0, $read))
   }
}

Ich hätte nie gedacht, dass der gestrige Flashmob-Versuch solch eine Aufruhr auf meinem kleinen, bescheidenen Blog erzeugt. In den Kommentaren zu meinem gestrigen Eintrag meldet sich ein Kritiker zu Wort, per Mailformular bekomme ich anonyme Hinweise, wer sich für die Aktion verantwortlich fühlt etc...

Disclaimer
Eines kurz zur Klarstellung: Diese Blog ist kein Flashmob-Blog. Ich habe lediglich aus lokalpatriotischem Antrieb etwas über den Flashmob geschrieben. Dieser Blog dient nicht zum Meinungsaustausch, zum bashen und flamen von Teilnehmern, Organisatoren etc. Mir unaufgefordert zugesendete Informationen ohne Absender werde ich nicht veröffentlichen. Ich fühle mich weiter nicht dazu verpflichtet, meine persönliche Meinungsäußerung vom gestrigen Tag zu widerrufen oder klarzustellen.

Wie man sieht, habe ich es nicht geschafft, der Shutdown Day-Bewegung zu folgen. Für mich war dieser bereits gestern. Heute gab es jedoch ein Ereignis, von dem berichtet werden muss:
In Siegen gab es einen Flashmob!
Laut der SchülerCC-Gruppe, die wohl die Hauptorganisation der Aktion durchführte, war dies der zweite Flashmob in Siegen. Ich war mit der Kamera vor Ort, konnte jedoch keine brauchbaren Ergebnisse erzielen.

Was ist ein Flashmob?
Laut Wikipedia ist ein Flashmob ein Blitzauflauf. Per Internet wird ein Treffpunkt organisiert, an dem sich dann scheinbar aus dem Nichts ein immenser Auflauf bildet. Der gesamte Mob führt dabei die gleiche Handlung aus. Nach der Aktion löst sich der Mob ebenso schnell in alle Richtungen auf, wie er sich gebildet hat.

Was in Siegen passierte?
Gegen 14:45 Uhr füllt sich langsam, aber sicher, das Erdgeschoss der dort ansässigen Einkaufsmeile. Die Sicherheitskräfte waren augenscheinlich eingeweiht, da teilweise Rolltreppen von anderen Stockwerken ins Erdgeschoss abgestellt wurden.  Gegen 14:55 Uhr war allerdings fast kein Durchkommen mehr. Von Passanten wurden wir gefragt, was denn hier los sei, worauf ein Bekannter sagte, es werde eine Autogrammstunde mit einem noch nicht bekannten DSDS-Teilnehmer geben. Gegen 15:00 Uhr konnte ich den angekündigten Pfiff vernehmen, worauf sich im vorderen Teil der Einkaufspassage alle auf den Boden legten. In dem Bereich, in dem ich mehr oder weniger eingeklemmt war, wurde der Pfiff gnadenlos ignoriert. Dadurch breitete sich das Ganze mehr als Laola durch die Passage, was jedoch den kollektiven Eindruck extrem störte. Nach noch nicht einmal einer Minute standen jedoch schon wieder alle, von den angekündigten zwei Minuten war also nur noch die Hälfte übrig geblieben. Somit war es für mich extrem schwer, aus der dunklen Ecke, in der ich eingezwängt war, in die helleren Bereiche vorzudringen. Als ich dort war, war das Spektakel bereits vorbei und es waren keine guten Bilder in der Kiste. Leider.

Persönliche Eindrücke

1. Gut, dass es eine Bewegung gibt, die absolut unpolitisch die verschiedensten Jugendgruppen anspricht.
2. Gut, dass die Jugendlichen mit solchen Aktionen feststellen können, dass sie es locker schaffen, den normalen Verkehr in einer Einkaufspassage komplett zum erliegen zu bringen.
3. Gut, dass es sehr viele Teilnehmer waren.
   
   
4. Schlecht, dass fast mehr Schaulustige als Teilnehmer anwesend waren.Schlecht, dass sich eine solche Menge (ich schätze ca. 300 Teilnehmer) nur auf zwei Haufen ballt. In vielen kleinen Gruppen auf allen drei Stockwerken wäre die Aktion viel imposanter gewesen.
5. Schlecht, dass eine von zwei Gruppen den Einsatz total verpennt.
6. Schlecht, dass es nur einen Organisator gab, der es nicht geschafft hat, die Gruppen zu verteilen, wobei er vorher bei beiden Gruppen mit Leuten gesprochen hat. Dort hätte es mehrere geben müssen, die sich auf die Aktion vorbereitet haben müssten.
7. Schlecht, dass es nicht sehr spontan aussah. Wenn man wusste, was passiert, konnte man bereits ab 14:35 Uhr die ersten Anzeichen erkennen.
   

Fazit
Bleibt zu hoffen, dass solche Aktionen in Zukunft wiederholt werden (natürlich nicht die selben) und dass sich die Organisatoren etwas mehr zutrauen. Lieber 50 Leute auf drei Stockwerken verteilen, als 300 auf einem Haufen. Und mir persönlich wäre es sehr lieb, wenn man die angekündigten Zeiten erstens einhalten und zweitens verlängern könnte. Denn nichts beschreibt einen Flashmob besser als Bilder. Bei solch kurzen Aktionen ist es jedoch extrem schwierig, vernünftige Resultate zu erzielen.

Durch Damir Tomicic darauf aufmerksam geworden; und nun bin ich auch dabei.

Und wieder hat der Code-Inside Blog einen sehr interessanten, diesmal weniger lustigen, weil leider wahren Artikel in seinem Blog veröffentlich. Allerdings hätte ich Mark durch Euro ersetzt; Was aber zeigt, dass das Problem bereits sehr lange bekannt und doch immer noch nicht gelöst wurde.

Ich musste gerade einige Zellen in Excel verbinden. Da mir das ewige Markieren - Rechtsklick - Zellen Formatieren - Zellen verbinden zu langsam war, habe ich nach einem Shortcut für diese Aktion gesucht. Leider bringt Excel so etwas nicht mit. Aber mit einem kleinen Macro kann man die Funktionalität nachrüsten:

Diese Makro wechselt nach der Zuweisung einer Tastenkombination den Status von mehreren Zellen von Nicht verbunden zu Verbunden und wieder zurück.

Sub Makro2()
    With Selection
        .HorizontalAlignment = xlGeneral
        .VerticalAlignment = xlBottom
        .WrapText = False
        .Orientation = 0
        .AddIndent = False
        .IndentLevel = 0
        .ShrinkToFit = False
        .ReadingOrder = xlContext
        .MergeCells = Not .MergeCells
    End With
End Sub

Komme gerade nach einem echt langen Tag nach Hause. Muss auch fast schon wieder zum nächsten Termin, aber will mal schnell schauen, was mein privater Posteingang noch Ansprechendes zu bieten hat. Da dort leider nichts Ansprechendes zu finden ist, stöber' ich noch schnell durch meine RSS-Feeds und finde dabei einen Blogpost von Robert Mühsig. Da ein bisschen Spaß im Büro nie schaden kann, fange ich an zu lesen. Aber vor allem zu lachen. Mit Tränen dabei. Ach, lange nicht mehr etwas so lustiges gelesen. Ich denke, ich werde morgen mal mit Punkt 1.5 beginnen :)

From a post ont the Windows Embedded blog - Microsoft announced some name changes for their embedded products:

• Windows Embedded CE is now known under Windows Embedded Compact
• Windows XP Embedded is now known under Windows Embedded Standard
• Operating systems wich embedded licences are now known under Windows Embedded Enterprise
• Point of Service applikations and platforms are now known under Windows Embedded POSReady
  

In der iX 5/2008 schreibt Dr. Holger Schwichtenberg:

Muschel verpackt

Die wegen ihrer Leistungsfähigkeit viel gepriesene PowerShell bietet bisher nur eine unkomfortable Benutzeroberfläche. Microsoft hat es bisher nicht geschafft, der Shell ein angemessenes GUI zu verpassen. Diese Lücke schließt nun das Third-Party-Tool PowerShellPlus.

Ich weiß ja nicht so genau, was Herr Dr. Schwichtenberg unter einer Shell versteht, aber für mich ist eine Shell eher Kommandozeileninterpreter als GUI. Ich denke, damit stehe ich nicht allein. Zugegeben; Ich habe den Artikel noch nicht gelesen und manchmal denke auch ich, dass es ein GUI hier und da etwas einfacher macht. Aber Shell bleibt Shell. Sonst könnte man es ja direkt MMC nennen. Außerdem ist die PowerShell als Ersatz für den Kommandozeileinterpreter cmd.exe gedacht, wenn man der Wikipedia glauben darf.

Mein Blog wird auf einem Windows 2003 Server gehostet. Da ich gerne wissen möchte, was dort so alles passiert, habe ich mir ein kleines Powershell-Script geschrieben, welches mir einmal pro Tag die Eventlog-Einträge des letzten Tages per E-Mail zusendet:

$sys = Get-Eventlog -list | Foreach-Object -process{Get-Eventlog $_.Log} | ?{$_.TimeGenerated -gt [DateTime]::Now.AddDays(-1)} |  ConvertTo-Html
$msg = New-Object Net.Mail.MailMessage("from@my.mail", "to@my.mail", "Daily Eventlog summary", $sys)
$msg.IsBodyHTML = $true
$smtp = New-Object NetMail.SmtpClient("mailserver.my.mail")
$smtp.Send($msg)

Was macht das Script genau?

Zuerst wird per
Get-Eventlog -list
eine Liste der auf dem System vorhandenen Eventlogs erstellt. Das Ergebnis wird an das Foreach-Object-Cmdlet gepipt, welches für jedes Element der Liste die Einträge abfragt:
Foreach-Object -process{Get-Eventlog $_.Log}
Die daraus resultierende Liste von Einträgen wird dann gefilter. Es sollen nur die Einträge weiterverarbeitet werden, die innerhalb des letzten Tages erstellt wurden:
?{$_.TimeGenerated -gt [DateTime]::Now.AddDays(-1)}
Diese Zeile kann auch als
Where-Object {$_.TimeGenerated -gt [DateTime]::Now.AddDays(-1)}
geschrieben werden, aber ? ist einfach etwas schneller.
Die gefilterten Einträge werden dann als HTML
ConvertTo-HTML
in der Variablen $sys gespeichert.
Im nächsten Schritt wird ein System.Net.Mail.MailMessage-Objekt erstellt, welches die HTML-Liste $sys der Eventlog-Einträge als Nachrichtentext übergeben bekommt.
$msg = New-Object Net.Mail.MailMessage("from@my.mail", "to@my.mail", "Daily Eventlog summary", $sys)
Die MailMessage-Instanz ist nötig, da wir eine HTML-Mail versenden wollen.
$msg.IsBodyHTML = $true
Möchten wir PlanText versenden, können wir den Nachrichtentext auch der $smtp.Send()-Methode übergeben.
Um die Mail per smtp.Send versenden zu können, muss erst der SmtpClient instanziiert werden. Im Konstruktor bekommt er den Mailserver übergeben, über der die Nachricht gesendet werden soll.
$smtp = New-Object NetMail.SmtpClient("mailserver.my.mail")
$smtp.Send($msg)

Im nächsten Schritt werde ich daraus ein kleines, konfigurierbares C#-Programm erstellen, das zum Beispiel verschiedene Ereignisquellen ausfiltern kann.

Da ich momentan eher mit C beschäftige, dort allerdings noch ein paar Fragen offen waren, hatte ich heute ein Code Review mit einem "alten Hasen". Dabei gab es eine Menge zu lernen. Als ich später mit meinem PM (der auch aus der C/C++-Welt stammt) das Review besprach, zeigt er mir einen netten kleinen Codeschnippsel: Duff's Device. Ich lasse das hier einmal ohne Erklärung stehen.

n = (anzahl + 3) / 4;
 
switch(anzahl % 4) {
    case 0:        do { ziel[stelle] = quelle[stelle]; stelle++;
    case 3:             ziel[stelle] = quelle[stelle]; stelle++;
    case 2:             ziel[stelle] = quelle[stelle]; stelle++;
    case 1:             ziel[stelle] = quelle[stelle]; stelle++;
                   } while(--n > 0);
}

Für meine C#-Augen war das ja gar nichts. Fallthrough im Switch-Statement. Brrr. Wenn das der Compiler sehen würde ;) Aber C ist eben etwas ganz anderes.

Mit Hilfe der String.Format-Methode können ja bekanntlich formatierte Einsetzungen in einen String vorgenommen werden. Im Ursprungsstring werden dazu Platzhalter in der Form {0}, {1}, etc eingefügt. Sind allerdings im Formatstring, als dem String, in den die neuen Teile eingesetzt werden, geschweifte Klammern enthalten, werden diese als Formatierungszeichen betrachtet. Aufgefallen ist mir dies bei der Formatierung der Zeichenkette:

#ifndef _BLABLUB_H_
#define _BLABLUB_H_

#  ifdef __cplusplus
  extern "C" {
#  endif /* __cplusplus */

BLABLUB sollte dabei durch den entsprechenden Namen der Headerdatei ersetzt werden. Allerdings hagelte es mit folgendem FormatString bei jedem Versuch, die formatierte Ausgabe zu erzeugen, eine FormatException.

public static string HeaderExklusionStart = "#ifndef {0}"
    + Environment.NewLine
    + "#define {0}"
    + Environment.NewLine
    + Environment.NewLine
    + "#  ifdef __cplusplus"
    + Environment.NewLine
    + "  extern \"C\" {"
    + Environment.NewLine 
    + "#  endif /* __cplusplus */";

Um den Fehler zu beheben, müssen einfach geschweifte Klammern, die ausgegeben werden sollen und somit nicht als Formatierungsanweisungen zu interpretieren sind, doppelt eingefügt werden:

+ "  extern \"C\" {{"

Auf den Fehler hingewiesen hat mich der Artikel Kombinierte Formatierung im MSDN. Prädikat: Wertvoll.

In meinem gestrigen Post String auf ASCII-Reinheit prüfen hat sich ein Fehler eingeschlichen. Die öffentliche Eigenschaft Encoding des StreamWriters ist ReadOnly. Um das Encoding des StreamWriters festzulegen, muss dieses im Constructur übergeben werden:

sourceWriter = new System.IO.StreamWriter( sourceFS, Encoding.ASCII );

Momentan liegt mein beruflicher Schwer