Dieser Artikel wurde maschinell übersetzt.

Synchronisierungsabdeckung

Codeabdeckung für Parallelität

Chris Dern

Beispielcode herunterladen

Wir sind an einen anderen Crossroads in der Branche als Transistor mehr und mehr Flusskrebse Prozessoren Multithreaded Code Ihre vollständigen Leistungspotenzial fordern.Während der Computer von Desktops zu Netbooks nicht weniger als Dual-Core-Prozessoren hinter den Kulissen Sportarten, sitzen Throngs des hungry Transistoren im Leerlauf--für Multithread-Anwendungen zu devour crying.Um die oncoming Wave gleichzeitigen Anwendungen zu beheben, sind Unternehmen wie Intel und Microsoft Rennen, auf den Markt mit Profilern, Frameworks, Debugger und Bibliotheken.Wie Multithreading-Anwendungen, dass proliferate zu Diskussionen von Deadlocks, live Sperren und Datenraces werden immer häufiger über die Softwarebranche.Software Development-Experten müssen, übernehmen neue Tools, Techniken und Metriken, die mit Multithreading Software verarbeiten können.

Codeabdeckung und Parallelität

Herkömmliche Abdeckung Codemetrik, wie z. B.-Anweisung, blockieren und Verzweigung fehlschlagen Adresse Test Eignung Bedenken durch Parallelität eingeführt wurden.Werfen wir als Beispiel Anweisung Abdeckung.Obwohl eine unvollständige Metrik Anweisung Abdeckung beliebte ist und es ist hilfreich zu einem gewissen Grad herausfinden, wie gründlich Sie Ihren Code getestet haben.Als ein Aktualisierungsprogramm misst Anweisung Abdeckung, wie viele Anweisungen von Ihrem Anwendungscode ausgeführt wurden.Es ist eine einfache Metrik, die von vielen Tools für Komponententests verwendet wird und viele Softwareentwicklungsteams hohe Anweisung Abdeckung als Balken Codequalität enthalten.Leider Anweisung Abdeckung nicht Ihnen eine beliebige Sichtbarkeit, wie viel von Parallelität in Ihrem Code getestet wird.

Abbildung 1 zeigt z. B. eine einfache Implementierung eines Typs threadsicher Warteschlange geschrieben in c# (in diesem Artikel wir verwenden C#- und für unsere Beispiele, aber das Konzept der Synchronisierung Abdeckung gilt für systemeigenen Code sowie).

In unserem Beispiel hat nur zwei Methoden: Warteschlange Dequeue und umschließt eine Warteschlange .NET < T >durch jede Enqueue umgebenden und Operation in einer Sperre Warteschlange zu entfernen.Wie können wir diese Warteschlange Implementierung testen?Der folgende Code zeigt einen einfachen Komponententest für unsere threadsicher Warteschlange:

void SimpleQueueTest() {
ThreadSafeQueue<int> q = new ThreadSafeQueue<int>();
q.Enqueue(10);
Assert.AreEqual(10, q.Dequeue());
}

Beachten Sie, dass diesen einfachen Test liefert uns 100 Prozent Anweisung Abdeckung, da diese einen Test ausführt jede Anweisung in unserer Implementierung Warteschlange.

Aber warten Sie, wir haben ein Problem--die Warteschlange sollen threadsicher sein, aber bisher wir haben getestet mit nur einen Thread! Wir sind nicht kritische Verhalten Testen der Grund war, warum wir dieses ThreadSafeQueue an erster Stelle implementiert. Anweisung Abdeckung erfahren wir, dass wir 100 Prozent Abdeckung, verfügen wenn wir verwenden einen Thread für einen Typ gleichzeitig zugegriffen werden soll. Anweisung Abdeckung ist natürlich an uns unzureichend wie viel von Parallelität Aspekte der der Code wir getestet haben. Was sind wir fehlt?

Abbildung 1 eine threadsichere Queue-Implementierung in c#

public class ThreadSafeQueue<T> {
object m_lock = new object();
Queue<T> m_queue = new Queue<T>();
public void Enqueue(T value) {
lock (m_lock) {
m_queue.Enqueue(value);
}
}
public T Dequeue() {
lock (m_lock) {
return m_queue.Dequeue();
}
}
}

Was wir fehlen ist eine Verzweigung innerhalb der Lock-Anweisung ausgeblendet. Genommen Sie an, dass wir die Sperre mit einem benutzerdefinierten primitive, z. B. die vereinfachte Implementierung einer Methode Spinlock Sperren wie folgt ersetzen:

void Acquire() {
while (!TryAcquire ()) {
// idle for a bit
Spin();
}
}

Die Enter-Methode ruft TryAcquire und wenn dies fehlschlägt, die Sperre (z.B.) abzurufen, das TryAcquire gibt false zurück, es ein wenig rotiert und erneut versucht. Wenn wir diese benutzerdefinierten Sperren Code mit unserer Warteschlange-Methode kombiniert, wie würde, die Anweisung Abdeckung auswirken? Der folgende Code zeigt, wie wir die Warteschlange mit benutzerdefinierten Sperren schreiben:

public void Enqueue(T value) {
while (!TryAcquire ()) {
//idle for a bit
Spin();
}
m_queue.Enqueue(value);
Release();
}

Nun, wenn wir unseren Test ausführen, sehen wir plötzlich Anweisung Abdeckung fehlt. Ein einzelner Thread Test wird die Anweisung Drehfeld vermissen, weil TryAcquire nur false zurück, wird wenn gab es einen anderen Thread, der bereits die Sperre besitzt. Die einzige Möglichkeit die Methode spin wird ist wenn einige andere Thread den kritischen Abschnitt eingegeben hat. Können nur die Spin-Anweisung behandelt Wenn Konflikte aufgetreten. Diese implizite Verzweigung innerhalb der Lock-Anweisung ist die Quelle der unsere Abdeckung Loch.

Synchronisierungsabdeckung

Da wir don’t jemand Lock-Anweisungen durch Ihre eigenen wechselseitigen Ausschluss Primitive ersetzen erwarten (noch tun wir Vertreter dadurch), müssen wir suchen eine Möglichkeit, diese ausgeblendeten Zweig verfügbar zu machen, sodass wir die Datenmenge Konflikte, die beim messen können, während unseres Tests. Forscher bei IBM stammt mit einem Code Coverage-Modell bezeichnet Synchronisierung Coverage, die genau dies tun können.

Sie können das Papier auf die im Abschnitt Weitere Informationen verwiesen wird gelesen, aber die grundlegende Idee ist einfach. Zunächst nehmen wir eine Synchronisierungsprimitiven--beispielsweise den .NET Monitor-Typ (der durch das Lock-Schlüsselwort in c# und dem SyncLock-Schlüsselwort in Visual Basic verwendet wird). Anschließend konnte an jedem Punkt im Code, wo eine Sperre wird erworbenen, aufzeichnen, ob Sie entweder (im Fall von, z. B. Monitor.Enter), blockiert oder andernfalls, die Sperre (z. B. mit Monitor.TryEnter). Entweder Ergebnis bedeutet, dass Konflikte aufgetreten. Folglich um zu sagen, dass wir über eine Sperre Abdeckung haben: ist es nicht ausreichend, um eine Lock-Anweisung ausgeführt wurdenWir müssen auch die Lock-Anweisung ausführen, während einige andere Thread die Sperre.

Während dieser Technik für systemeigenen und verwalteten Anwendungen gilt, besprechen der Rest dieses Artikels unsere verwalteten Lösung--ein Prototyp Synchronisierung Coverage Tool für .NET bezeichnet Synchronisierung behandelt.

Nehmen Sie sich nun einen Moment Zeit zu verdeutlichen die Konzepte von unserem Coverage Tool verwendet. Ein Punkt Synchronisierung ist einer bestimmten lexikalischen Aufruf-Website eine Synchronisierungsmethode aufruft. Dauert eine schnelle wieder in unserem Beispiel threadsicher Warteschlange (Abbildung 1), bei unserer C#-Compiler auf, sehen wir zwei solche stellen, die in die Lock-Anweisungen in Warteschlange und Dequeue ausgeblendet. Nach jeder einzelnen Ausführung sind wir zwei Arten von Codeabdeckung interessiert: Anweisung Coverage, bei dem die Methode nicht mit alle Konflikte; auftritt,und Konflikte Coverage, in denen die Methode gezwungen wurde blockiert, oder warten Sie ein anderer Thread freizugeben.
Für den Rest des in diesem Artikel liegt der Schwerpunkt insbesondere auf System.Threading.Monitor, das Pferd Arbeit der Synchronisierung .NET stabil. Jedoch ist es sinnvoll, gleichermaßen dieser Ansatz funktioniert gut mit anderen Primitive wie System.Threading.Interlocked.CompareExchange.

Round-Tripping mit IL

Unser Ziel für diese Synchronisierung Coverage Tool ist transparent vorhandenen .NET Assemblys instrumentieren, wir abfangen jedem Monitor.Enter-Aufruf in der Assembly und bestimmen, ob, zeigen Sie synchronisieren können Konflikte auftreten. Wie ein Großteil der Code Coverage Lösungen in heute wendet unsere Tool Techniken, die IL (die .NET Intermediate Language) zum Erzeugen von instrumentierten Versionen der Assemblys Ziel zu schreiben. Obwohl wir einen Großteil unsere Zeit in c# verbringen, sollten dieses Tool direkt mit der IL theoretisch Umgang für alle .NET Sprachen arbeiten, die in IL kompiliert.

Es gibt einige mögliche Technologien damit Code umgeschrieben, einschließlich der neu veröffentlichten Common Compiler Infrastruktur von Microsoft Research (MSR) haben Einfachheit wir auf die vertrauenswürdigen IL-Compiler und Decompiler Kombinationsfeld ILASM und ILDASM zurückgreifen. Ein großer Segen während der Ermittlung, Entwurf und Entwicklung Phasen des Projekts, uns Entwurfsentscheidungen in einer "Lohn-für-Play" Erkunden aktivieren werden erwies arbeiten direkt mit der IL in nur-Text-Dateien alsAnsatz mit unserer Zeit Kapitalanlage. Wir erwies als der Entwicklungsfähigkeit und Durchführbarkeit unsere Lösung am zuerst über einen vollständig manuellen Prozess umfasst Batchdateien und Editor. Obwohl dies am besten für eine Produktion Qualität Tool möglicherweise nicht, empfehlen wir diesen Ansatz für alle ähnlichen Prototyp Anwendung neu zu schreiben.

Mit dieser allgemeinen Entwurfsentscheidung abgeschlossen wir eine kurze Tour unsere Kette Tool wie in Abbildung 2 dargestellt.

Mithilfe von ILDASM, dekompilieren wir die Zielassembly in eine Textdatei mit der IL-Anweisungen. Wir werden dann den Quellcode in den Arbeitsspeicher hinter einer Fassade objektbasierte geladen. Wir wenden Sie dann die erforderlichen Änderungen, und Code-Injektionen des Codes, Ausgeben der geänderten Quelle wieder auf den Datenträger. Es ist nur eine einfache Frage der Neukompilierung der abgedeckten Assembly mit ILASM und mit PeVerify catch alle alberne ungültigen Transformationen überprüfen wir möglicherweise angewendet haben. Wenn wir unseren Assemblys Abdeckung haben, haben wir unsere Testlauf wie gewohnt ausführen und erfasst die Common Language Runtime Abdeckung Datei für die spätere Analyse.

Unsere Toolset besteht aus zwei Hauptkomponenten: Sync-Abdeckung, die automatisiert diesen Prozess Instrumentation und bietet eine INTEGRITÄTSSTUFE round-Trip-Plattform von denen wir unsere Instrumentation; erstellenund Abdeckung-Funktion, eine Windows Presentation Foundation (WPF)-Anwendung, die eine vertraute und intuitive Möglichkeit, die Codeabdeckung Dateien untersuchen bereitstellt.

Erfassen Konflikte

Mittlerweile sollten Sie fragen sich werden wie wir beobachten und aufzeichnen, wenn ein Sync-Punkt Konflikt auftritt. Betrachten der "ausgeblendet-Branch" zurückIhre Modell wie Monitor.Enter implementiert konnte bietet uns einen Hinweis, wenn wir es fast buchstäblich in unserer Transformation anwenden. Wir sehen, in der vorhergehenden vereinfachte Implementierung des ein Spinlock Code, einlesen Methode diese genaue Informationen im Rückgabewert erfasst. Wir müssen dazu ist es angezeigt wird.

Als wir andere Personen IL schreiben möchten, verspricht beliebige Verzweigungen einfügen, eine Pandora's Probleme öffnen wir statt vermeiden möchten. Das zweite Problem des Aufzeichnens und verknüpfen die Synchronisierung zeigen Daten abrufen schlägt wir unsere Programmierer Tool im Feld aktivieren und für einige Dereferenzierung erreichen.

Wir lösen beide Probleme durch die Einführung einer Wrapperklasse--eine Synchronisierung Coverage-fähigen Fassade über Systemmonitor, deren Methoden ein SyncId-Argument akzeptieren. Dieses SyncId ist eine generierte eindeutige ganze Zahl, die einen Punkt Sync eindeutig--, wir bieten jeden Punkt Synchronisierung eine eindeutige Kennung, und wenn wir einen Sync-Punkt erreicht, übergeben wir die ID an unsere Wrapperklasse. Unsere Implementierung Abdeckung beginnt mit dem aufrufenden Monitor.TryEnter das Ergebnis aufzeichnen und dann bei Bedarf an der ursprünglichen blockieren Monitor.Enter delegieren. Synchronisierung Punkt besagt verwaltet werden durch eine einfache im Speicher befindlichen Datenbankklasse rufen wir die CoverageTracker. Alle Teile zusammenstellen, sieht unsere Version Abdeckung Monitor.Enter, wie in Abbildung 3 dargestellt.

Abbildung 3 Coverage-Version von Monitor.Enter

namespace System.Threading.SyncCover {
public static class CoverMonitor {
public static void Enter(object obj, int syncId) {
if (Monitor.TryEnter(obj)) {
coverageTracker.MarkPoint(syncId, false); // No Contention.
} else {
Monitor.Enter(obj);
coverageTracker.MarkPoint(syncId, true); // Contention
}
}
}
}

Beachten Sie, dass der Code in Abbildung 3 Monitor.Enter-Version .NET 3.5 unterstützt dient. Der bevorstehende .NET 4 überwachen Typ enthält Änderungen, die flexibel vor asynchronen Ausnahmen vornehmen – finden Sie unter blogs.msdn.com/ericlippert/archive/2009/03/06/locks-and-exceptions-do-not-mix.aspx. Hinzufügen von Unterstützung für .NET 4 Überladungen ist nur eine Frage der Überlastung der Wrapper in einen ähnlichen fashion.Once haben wir unsere Methode in hand, des Instrumentationsvorgangs wird ziemlich direkt vorwärts. Sehen wir uns die IL von .NET 3.5 C#-Compiler für die Lock-Anweisung wie folgt erstellt:

IL_0001: ldfld object class ThreadSafeQueue'1<!T>::m_lock
IL_0002: call void [mscorlib]System.Threading.Monitor::Enter(object)

Wir müssen nur Aufrufe an Monitor.Enter suchen und Ersetzen Sie durch Aufrufe an unsere CoverMonitor.Enter beim Argument zusätzliche SyncId vor dem Methodenaufruf einzuschleusen nicht vergessen. Der folgende Code veranschaulicht diese Transformation:

IL_0001: ldfld object class ThreadSafeQueue'1<!T>::m_lock
I_ADD01: ldc.i4 1 // sync id
IL_0002: call void System.Threading.Coverage.Monitor::Enter(object, int32)

Als letzten Teil dieser Prozess sollten wir etwas sprechen über reporting ist und welche Art von Informationen nützlich. Bisher, wissen wir über die Synchronisierung Punkte, die durch eine SyncId, direkt in den Ziel-Quellcode eingefügt identifiziert werden. Es wäre viel nützlicher, wenn wir die Quelldateien und Zeilennummern jedes Punktes Synchronisierung erhalten konnte. Wir gefunden ILDASM mit der Option /LINENUM uns die Informationen sind, die wir durch Extrahieren Quelle Dateispeicherorte und Zeilennummern aus die Programmdatenbank (PDB müssen).

Wenn wir einen neuen Synchronisierung Punkt während des Instrumentationsvorgangs auftreten, haben wir nächste SyncId generieren und erfassen diese Kontextinformationen in einer Zuordnung. Diese Zuordnung, wie in den folgenden Code wird dann als eine Datei am Ende der Instrumentation ausgegeben:

T|ThreadSafeQueue.exe
SP|
0|D:\ThreadSafeQueue\ThreadSafeQueue.cs|9|ThreadSafeQueue`1<T>|Enqueue
1|D:\ThreadSafeQueue\ThreadSafeQueue.cs|15|ThreadSafeQueue`1<T>|Dequeue

Abbildung 4 ausführen Beispiel Coverage

~|B3|~
A|ThreadSafeQueue.exe
C|ThreadSafeQueue.exe
D|20090610'091754
T|demo
M|DWEEZIL
O|Microsoft Windows NT 6.1.7100.0
P|4
SP|
0|1|1
1|1|0
~|E|~

Die Daten Me anzeigen!

Es ist Zeit anzeigen. Wenn wir unsere abgedeckten Binärdateien haben, ist es eine einfache Frage der Ausführung des Programms beliebig viele Durchläufe. Dies erzeugt eine Common Language Runtime-Datei, enthält die Abdeckung Metriken, die während der Ausführung gesammelt wurden, wie in Abbildung 4 dargestellt. Notizen Inspiration aus anderen Coverage Tools auf dem Markt, stellen wir einfachen WPF-Viewer, die Abdeckungsergebnisse darzustellen.

Aber wir Schritt für einen Moment zurück. Wir wissen, dass unsere Singlethread-Test Case Null Prozent Synchronisierung Abdeckung uns wird. Wie können wir den Test beheben, damit wir Konflikte verursachen können? Abbildung 5 zeigt einen leicht verbesserten Test, der in der Warteschlange Methode Konflikte verursachen sollte. Nach Ausführung des Tests, ersichtlich die Ergebnisse wie in Abbildung 6 dargestellt.

Hier sehen wir die drei mögliche Abdeckung Fällen für einen bestimmten Synchronisierung Punkt. In diesem Beispiel sehen wir, dass Warteschlange mindestens Anzahl der Konflikte festgestellt und so in grün angezeigt. Aus der Warteschlange entfernt, andererseits ausgeführt wurde, aber nicht behaupten, wie in gelb dargestellt. Wir haben auch eine neue Eigenschaft Count nie aufgerufen wurde, hinzugefügt und wird als Rot.

Abbildung 5 ein Test, der Konflikte verursacht auf Warteschlange

void ThreadedQueueTest()
{
ThreadSafeQueue<int> q = new ThreadSafeQueue<int>();
Thread t1 = new Thread(
() =>
{
for (int i = 0; i < 10000; i++)
{
q.Enqueue(i);
}
});
Thread t2 = new Thread(
() =>
{
for (int i = 0; i < 10000; i++)
{
q.Enqueue(i);
}
});
t1.Start();
t2.Start();
t1.Join();
t2.Join();
Assert.AreEqual(0, q.Dequeue());
}

Mithilfe der Synchronisierung Coverage

Daher sollte Wenn wir Synchronisierung Abdeckung verwenden? Wie alle Code Coverage Metrik versucht Synchronisierung Abdeckung messen, wie Sie Ihren Code getestet haben. Jede Art von Sperren in Ihrer Anwendung bedeutet, dass Ihr Code wurde sollen gleichzeitig zugegriffen werden und Sie ernsthaft neugierig sein, ob Ihre Testsuite tatsächlich diese Sperren ausführt. Ihr Team sollte bei 100 Prozent Synchronisierung Abdeckung sollte, insbesondere, wenn die Anwendung erwartet, parallel viel ausgeführt.

Möchten üben, was wir preach, haben wir diese Synchronisierung Coverage Tool im Verlauf der Tests die Parallel Extensions to .NET Framework verwendet. Hat geholfen, uns während dieser Entwicklungszyklus testen Löcher und Fehler suchen, und wir weiterhin mit die Metrik Zukunft erwarten. Zwei Szenarien, in denen Synchronisierung Abdeckung uns geholfen hat, sind besonders interessant:

Nicht gleichzeitige Multithread-tests

Synchronisierung Abdeckung, die einige Tests gefunden, die wir ausgeführt wurden, gleichzeitig waren tatsächlich nicht. Abbildung 7 ist ein einfaches Multithreaded Test Abbildung 5, aber diesmal jeder Thread Enqueues nur 10 in die Warteschlange Elemente ähnlich.

Abbildung 7 A gleichzeitig testen, nicht gleichzeitig sein kann, nachdem alle

void ThreadedQueueTest() {
ThreadSafeQueue<int> q = new ThreadSafeQueue<int>();
Thread t1 = new Thread(
() => {
for (int i = 0; i < 10; i++) {
q.Enqueue(10);
}
});
Thread t2 = new Thread(
() => {
for (int i = 0; i < 10; i++) {
q.Enqueue(12);
}
});
t1.Start();
t2.Start();
t1.Join();
t2.Join();
}

Nur weil wir zwei Threads gestartet, jedoch bedeutet nicht, dass Sie tatsächlich parallel ausgeführt werden. Was wir gefunden wurde, dass diese Arten von Tests mit sehr kurzen Ausführungszeiten pro Thread häufiger ein Thread nach der andere Thread vollständig ausgeführt haben. Wir möchten einen Test, bei dem konsistent Konflikt auftritt. Eine Lösung ist jeder Thread Enqueue Weitere Elemente, damit es wahrscheinlicher, dass Konflikte verursachen. Eine bessere Lösung ist die Verwendung ein Tools wie CHESS, was jedes überlappende zwischen den beiden Threads auftreten.

Unnötige Sperren

Es ist durchaus möglich, dass einige Synchronisierungspunkte nicht abgedeckt wird sind, da Sie nicht abgedeckt werden können. Im folgenden Codebeispiel wird, wenn die Sperre b immer erworben haben, wenn die Sperre für eine gehalten wird, um die Sperre b: decken unmöglich ist

lock(a) {
lock(b) {
//... stuff ...
}
}

Erstaunlich, wurde Synchronisierung Abdeckung tatsächlich uns unnötige Sperren wie diese Suchen geholfen. Wie sich herausstellt, dass manchmal eine Ressource durch eine Sperre geschützt mehr möglicherweise werden muss. Beispielsweise ein Thread, der u. über die Ressource u. möglicherweise nicht mehr benötigt und aus dem Code entfernt, aber die Sperre auf den verbleibenden Thread wurde nicht entfernt. Zusätzliche Sperren ist zwar harmlos im Sinne von Verhalten, konnte es weiterhin Leistung beeinträchtigt. (Beachten Sie jedoch, nur weil eine Sperre nie für contended ist bedeutet, dass nicht es nicht erforderlich; istsolche Informationen stellt lediglich einen Ausgangspunkt einer Untersuchung um zu bestimmen, ob es tatsächlich erforderlich ist.)

Einschränkungen und zukünftiger Arbeiten

Wie alle Code Coverage Metrik Synchronisierung Coverage ist nicht perfekt--es hat Ihre Grenzen. Eine chief Einschränkung, die Synchronisierung Abdeckung Freigaben mit anderen Abdeckung Metriken ist messen kann nicht was nicht vorhanden ist. Synchronisierung Abdeckung kann nicht Ihnen mitteilen, dass Sie über eine Ressource zu sperren, die die Ressourcen gesperrt haben über contended wurden haben benötigen. Folglich auch 100 Prozent Synchronisierung Abdeckung bedeutet nicht, dass Ihre Tests Aufwand, nur erfolgt, dass Sie gewisse Gründlichkeit in Ihren Tests erreicht haben.

Ein weiteres Problem ist, Instrumentieren von Code für die Synchronisierung Abdeckung die Terminplanung des Threads in die Tests ändern konnte, so dass Sie Abdeckung in Ihrer instrumentierte Testlauf jedoch nicht in Ihre uninstrumented Ausführung erhalten (Obwohl in unserer Erfahrung wir gefunden haben, dass dies normalerweise kein Problem aufgetreten ist). Erneut, ein Tool wie CHESS helfen können. Unsere Prototyp-Tool ermöglicht uns, Konflikte über Systemmonitor und Interlocked-Vorgänge zu messen. In der Zukunft planen wir Hinzufügen von Features, die uns andere Synchronisierungsprimitive wie Semaphore und ManualResetEvent messen. Wir glauben, Code Coverage Metrik, wie Synchronisierung Abdeckung werden konnte wie nützlich und weit verbreiteten für parallele Anwendungen als Anweisung Abdeckung für Singlethread-Anwendungen.

Ein müssen messen

Sie können nicht verbessern, was Sie messen nicht möglich. Daher müssen wir wir mehr und mehr Multithreadanwendungen Software entwickeln, messen wie gründlich wir die Parallelität Aspekte unserer Software getestet haben. Synchronisierung Coverage ist eine einfache, praktische Möglichkeit dazu. Wir hoffen, dass diese ganz neue Welt der Multi-Core Datenverarbeitung navigieren, Sie die Ideen in diesem Artikel zur Verbesserung des Qualität Prozess durchführen können.

Weitere Informationen

• Parallele Datenverarbeitung bei Microsoft:
  MSDN.Microsoft.com/Concurrency
• Synchronisierung Abdeckung Papier:
  Bron, a, Farchi, e, Magid, j., Nir, j., und Ur, S. 2005. Anwendungen der Synchronisierung Abdeckung. In Proceedings der zehnten ACM-SIGPLAN-Symposium Prinzipien und Methoden der parallelen Programmierung (Chicago, Ill., USA, Juni 2005 15-17). PPoPP ' 05. ACM, New York, n.y. 212 206.
• CHESS-Tool:
  research.microsoft.com/projects/chess/default.aspx
  Musuvathi M. und Qadeer, S. 2007. Iterative Kontext umgebenden systematische Tests für Multithread-Programme. In Proceedings der 2007 ACM SIGPLAN Conference auf Programming Language Entwurf und Implementierung (San Diego, Kalifornien, USA, Juni 10-13, 2007). PLDI ' 07. ACM, New York, N.Y., 446-455.
• Common Compiler-Infrastruktur (CCI):
  ccimetadata.CodePlex.com

Roy Tan ist ein Software Development Engineer im Test mit der Parallel Computing Platform-Gruppe bei Microsoft. Er empfangen seinen Bereich in der Informatik an Virginia Tech in 2007.
Chris Dern ist eine Parallelität Software Development Engineer in Test für das Parallel Computing Platform-Team bei Microsoft--wobei lediglich besser als das Schreiben von Parallelität Software es testen ist.