Multithreading im Zeichen von Mehrkernprozessoren · must not attempt to start, stop, suspend, or...

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]: 1.1

Schneller fahren aufmehr Spuren?

Multithreading im Zeichen vonMehrkernprozessoren

Steffen Schluff

Papick Garcia Taboada

© 2007 Orientation in Objects GmbHMultithreading im Zeichen von Mehrkernprozessoren 2

Schneller fahren auf mehr Spuren?Überblick

• Die neue bekannte Herausforderung– Motivation, Probleme

• Multithreading und Enterprise Architekturen– Betrifft mich das auch?– Aber J2EE sagt doch…

• Was tun als Programmierer ???– Concurrency Utils

• Concurrent Collections, Executor Framework, ...– Tips, Tricks und Tools

• Javadoc, Lint, Immutability, ...

2















3


Das Multi-Core Dilemma…

Diskussionen gerade sehr aktuell…

java.util.concurrency Package…

JSR 166, JDK 1.5…

Java Concurrency in Practice…

Krieg der Kerne, iX…

Blog von Patrick Leonard, Diskussion of TSS…

Keynote von Tim Bray auf der WJAX 2006…

Verschiedene Sessions auf der JAX 2007

Patrick Leonard

Brian Goetz

Tim Bray

Doug Lea


Schneller fahren auf mehr Spuren?

• Die neue bekannte Herausforderung

• Multithreading und Enterprise Architekturen

• Was tun als Programmierer ???

4


Schluss mit Lustig?

• Seit 30 Jahren konstanter CPU Performance Anstieg

– Taktfrequenz,Ausführungs-optimierung,Cache

– SichererPerformanceGewinnfür Software


2007 und noch immer keine Lösung…

• CPU Taktfrequenz beginnt zu schwächeln

– Bisheriger Trend endet circa 2004

– Probleme: Wärmeentwicklung, Stromverbrauch, Leckströme

– Neue Ansätze versprechen immer wieder schnellere Prozessoren,bisher aber keine Produktionsreife erreicht

5


Entwicklung Taktfrequenz

0,1

1

10

100

1000

100001970 1975 1980 1985 1990 1995 2000 2005 2010

JahrTa

ktfre

quen

z (M

hz)


Free lunch is over?

Quelle: commons.wikimedia.org

6


Moore hat immer noch recht!

• Wachstum der Transistordichte noch vorhanden (Moore‘s Law)

• Hardware Hersteller satteln um– Hyperthreading, Caches

– Multicore-Technik• braucht wenig Platz• kein völlig neues Design• günstigere Energiebilanz

– Bei Erhöhung des Taktes steigt der Energiebedarf zum Quadrat– Bei Erhöung der Kerne steigt der Verbrauch „nur noch“ linear an


Wie sind die veränderten Prognosen für dieZukunft?

• Cache Wachstum beschleunigt Anwendungen auch weiterhin

• Aber Multithreading/Multicore beschleunigt Software nicht vonselbst

– Viele Anwendungen sind nicht für Mehrprozessorsysteme Entwickeltworden, laufen schließlich nur auf einem (meist langsameren Kern)

7


Wie läßt sich Hardware Wachstum weiteroptimal nutzen?

• Umdenken in der Entwicklung erforderlich

• „Concurrent software“ wird zunehmend wichtig werden


Neue Herausforderungen für SoftwareEntwickler

• Neue Architekturen, APIs und Technologien

• Umdenken im Bereich Testen und Performance

8


Offene Fragen,neue Problemstellungen

Increasing success bylowering expectations

http://www.despair.com

„No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them“


Multithreading, ist das was neues?

Wikipedia, Multithreading

Der Begriff Multithreading (auch Mehrfädigkeit) bezeichnet daszeitgleiche Abarbeiten mehrerer Threads (das sindAusführungsstränge innerhalb eines einzelnen Prozesses odereines Tasks).

9


Java Buzzwordbingo!

The Java programming language is a high-level language thatcan be characterized by all of the following buzzwords:

SimpleArchitecture neutralObject orientedPortableDistributedHigh performanceMultithreadedRobustDynamicSecure

Quelle: The Java Tutorials, The Java Technology Phenomenon


Java Buzzwordbingo!

The Java programming language is a high-level language thatcan be characterized by all of the following buzzwords:

SimpleArchitecture neutralObject orientedPortableDistributedHigh performanceMultithreadedRobustDynamicSecure

Quelle: The Java Tutorials, The Java Technology Phenomenon

10


Also…Java kann doch Multithreading!

• Java unterstützt seit Beginn Multithreading

– synchronized,– volatile– wait()– notify()– notifyAll()– Collections.synchronized[Collection|List|Set|Map](…)– U.s.w. …


Aber…Können wir es?

• In der Praxis aber schwer anwendbar

– Multithread Programmierung syntaktisch einfach,aber keineswegs trivial!

– Komplizierte Konstrukte mit niedrigem Abstraktionsgrad

– In reiner Form ungeeignet für Anwendungsentwicklung

11


Wie gut ist die eigene Lösung?

• Jeder kocht sein eigenes Süppchen

– Viele hausgemachte Ad-Hoc Lösungen

– Eigene Lösungen oft unausgegoren und nur schwer testbar

Einarbeitungszeit für neue Mitarbeiter?

Testbarkeit?

Dokumentation?


Java, Threads und…CPUs?

Angenommen,wir (Entwickler) sind in der Lage ConcurrentSoftware zu entwickeln,wie werden meine Threads auf CPUs verteilt?

12


Mehrere CPUs in Java nutzen

• Java stellt keine eigene Funktionenzur Prozesskontrolle undProzesssteuerung bereit

– Je nach OS verschiedeneAnsätze

– OS Frage als Platform (wieder)Aktuell?

Verschiedene Arten von Threads(aus Sicht der VM)

Green ThreadsThreads „nurinnerhalb“ einer VM

Native Threads (heuteStandard)

Java Threads werdenauf Betriebsystemprozesseabgebildet Betriebsystemist für Scheduling

zuständig


CPU Affinity?

Bug ID: 4234402Synopsis: (thread) Thread.setCPUAffinity?State: Closed, will not be fixed

(…)But this is ignoring the basic fact that only the mostsophisticated Java users could expect to gain real advantagewith such a feature (i.e. by making better scheduling choices thanthe operating system would make without use of the feature)(…)

Quelle: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4234402

13


Java & Windows

• Native Threads sind Win32 Threads

– Windows ist für Schedulingund Synchronization zuständig

– Tools zur Überwachung sind imWindows Softwareumfeld zu suchen

– „Leistung“ (perfmon.msc) bietetviele Überwachungsmöglichkeiten


Visualisierung mit Perfmon.msc

14







Wo helfen viele Prozessoren?

• Virtualisierung von Rechnern– Xen, VM Ware, OpenVZ, u.v.a.

• Erhöhung der Performanceeinzelner Server bzw. Dienste die bereitsMultithreaded sind

– Application Server– Mail Server– U.s.w.

15


Eigentlich nichts Neues

• „Enterprise“ Hardware schon seit längerer ZeitMultiprozessorbasiert– Symmetrisches Multiprocessing ist seit Ende der 80er Jahre die

Standard-Architektur für Multiprozessor-Maschinen mit bis zu 16CPUs.

• Java Enterprise Edition adressiert thread safety und concurrencybereits in der Architektur

• Warum also erst jetzt die ganze Diskussion?


Hardware…

16


Und (Enterprise) Software…

• Java wird stark im Umfeld Unternehmenskritischer Anwendungeneingesetzt

– Java Enterprise Edition

• Java EE Architekturen vereinfachendie Softwareentwicklung

- Laufzeitumgebung- Schnittstellen- Programmiermodell- Vorschriften bzw. Restriktionen


Java EE Architektur, EJBs

The Enterprise JavaBeans architecture will make it easy to writeapplications: application developers will not have to understand low-leveltransaction and state management details, multi-threading, connection pooling, orother complex low-level APIs.

The enterprise bean must not attempt to manage threads. The enterprise beanmust not attempt to start, stop, suspend, or resume a thread, or to change athread’s priority or name. The enterprise bean must not attempt to manage threadgroups.These functions are reserved for the EJB container. Allowing the enterprise beanto manage threads would decrease the container’s ability to properly manage theruntime environment.

Quelle: Enterprise JavaBeans 3.0 Final Release

17


Java EE Architektur

The Enterprise JavaBeans architecture will make it easy to writeapplications: application developers will not have to understand low-leveltransaction and state management details, multi-threading, connection pooling, orother complex low-level APIs.

The enterprise bean must not attempt to manage threads. The enterprise beanmust not attempt to start, stop, suspend, or resume a thread, or to change athread’s priority or name. The enterprise bean must not attempt to manage threadgroups.These functions are reserved for the EJB container. Allowing the enterprisebean to manage threads would decrease the container’s ability to properly managethe runtime environment.

Quelle: Enterprise JavaBeans 3.0 Final Release


Java EE und „thread safety“

• Prinzipiell sorgt ein Application Server dafür, dass dieKomponenten sich nicht um „thread safety“ kümmern müssen

– Das bezieht sich aber nur auf EJBs• z.Bsp. werden SLSB werden mehrfach instanziert um exklusivität

(und dadurch Threadsafety) während eines Methodenaufrufs zugarantieren

– Servlets sind Singletons und werden u.U. von verschiedenen Threadsgleichzeitig aufgerufen, müssen also Threadsafe sein.

• Thread Synchronization ist keine Lösung

• Das Interface SingleThreadModel ist „deprecated“seit Servlet API 2.4

18


Java EE und „thread safety“ Fazit

Nur EJB Anwendungen sind „out of the box“ thread safe

– Gut:• Entwickler muss sich nicht um Threads und Threadsafety kümmern

• Anwendung skaliert in Bezug auf Anzahl der Anfragen/ Clients ohnezutun des Entwicklers

– Schlecht:• Entwickler kann keine Threads starten und somit keine

Lösungsansätze anstreben, die Nebenläufigkeit einbeziehen

• Anwendung skaliert nicht in Bezug auf Komplexität derBusinesslogik wenn sequentielle Algorithmen versagen


Problembereich Webanwendungen

• Thread safety in Webanwendungen nicht immer gegeben

– „Wir brauchen keine EJBs. Wir wollen nur eine einfacheWebanwendung bauen“

• Anmerkung: Es gibt nicht sowas wie eine „EinfacheWebanwendung“

– Viele Webanwendungen verzichten auf EJB-Schicht

– Entwickler müssen sich mit „thread safety“ auseinandersetzen

• Was kümmer mich „thread safety“? Bin doch J2EE Entwickler…• „Know How“ vorhanden?

19


Ist Spring die Rettung?

• Teilweise…


Solving other peoples‘ problems…

Die mit Spring mitgelieferten „Data Access Templates“sind thread safe.

Dadurch wird die Implementierung einer DAO Schicht innerhalbeiner Webanwendung deutlich vereinfacht.

20


Vorsicht…

• Die in Spring konfigurierte business Schicht (services) müssen jenach Umfeld „thread safe“ entwickelt werden.

• Dennoch muss sich ein Entwickler mit der Tatsacheauseinandersetzen, dass thread safety in einer Webanwendungnicht gegeben ist und das entsprechende Know How aufbauen


Project Danger?

21







Der Silberstreifen am Horizont

• Pionierarbeit durch Doug Lea– Web Page und Veröffentlichungen seit Ende der 90er– Entwicklung eigener Java API (EDU.oswego.cs.dl.util.concurrent)

• Einrichtung JSR 166– „... provide functionality commonly needed in concurrent programs.“– Geleitet durch Doug Lea

• Ergebnis „Concurrency Utilities“– Seit Java 5 fest im JDK (java.util.concurrent)– Etwas untergegangen im Sprachfeature Trubel– Diverse Erweiterungen in Java 6

22


Concurrency Utilities Bestandteile (1)

• Stellt fertige Bausteine zur Verfügung– Für alle Arten von Entwicklern (Anwendung, Server, Concurrent, ...)

• Concurrent Collections– Spezielle Implementierungen von Map, Set, List, Queue, Deque

• Executor Framework– Framework zur Ausführung asynchroner Tasks


Concurrency Utilities Bestandteile (2)

• Synchronizers– Hilfsklassen zur Koordination mehrerer Threads– Semaphore, CountDownLatch, CyclicBarrier, Exchanger

• Locks und Conditions– Lock ist Objekt Repräsentation von synchronized– Condtion kapselt Monitor Methoden wait(), notify und notifyAll()

• Atomic Variables– Atomare Manipulation einzelner Variablen– Erlaubt Hardware Compare-And-Swap (CAS) zu nutzen

23


Klassiker

• „Thread-Safe“ Datenstrukturen in Java bereits vorhanden– Vector, Hashtable– Synchronized Wrapper aus java.util.Collections: synchronizedList(), ...

• Sicherheit durch Synchronisierung aller Zugriffsmethoden– Grob granulares Locken der ganzen Collection– Skaliert schlecht bei Zugriff aus vielen Threads („Multicore anyone?“)

• Synchronisierung durch Client häufig notwendig– Mehrschrittige Operationen (deleteLast, putIfAbsent, ...)– „Fail-fast“ Iteratoren (ConcurrentModificationException)


Überraschung

List<String> ls =Collections.synchronizedList(new ArrayList<String>());

...

// Verhalten kann undeterministisch sein// Kann ConcurrentModificationException werfen

Iterator<String> i = ls.iterator();

while (i.hasNext()) {foo(i.next());

}

...

24


Gut Ding will Weile haben

List<String> ls =Collections.synchronizedList(new ArrayList<String>());

...

// Client synchronisiert// Blockiert anderen Zugriff während Iteration

synchronized(ls) {Iterator<String> i = ls.iterator();while (i.hasNext()) {

foo(i.next());}

}

...


Concurrent Collections

• Unterscheidung „Thread-Safe“ und „Concurrent“– Neue Implementierungen der klassischen Strukturen (List, Map, Set)– Ab Java 6 auch für SortedMap und SortedSet

• Erlauben nicht blockierenden (skalierbaren) parallelen Zugriff– Standardfall: Paralleles Lesen aus mehreren Threads– Nachteil: Kleinere semantische Anpassungen notwendig

• Iteratoren „weakly consistent“ statt „fail-fast“– Kein komplettes Locken und keine ConcurrentModificationException– Iterator darf Änderungen seit seiner Erzeugung ignorieren

25


Klassiker, again

• ConcurrentHashMap– Fein granulareres Locken erlaubt paralleles Lesen und Schreiben– Kein Client-Lock, dafür neue atomare Methoden (putIfAbsent, ...)

• CopyOnWriteArrayList / CopyOnWriteArraySet– Array basierte Liste, Veränderung führt zu neuer Array Kopie– Ideal falls lesen deutlich häufiger als schreiben

• ConcurrentSkipListMap (ab Java 6)– Implementierung des SortedMap Interface– Wird auch verwendet für ConcurrentSkipListSet


Neuzugänge vorne anstellen

• Neues Collection Interface Queue– Datenstruktur, die Elemente für eine Verarbeitung bereit hält

• Neues Collection Interface BlockingQueue– Methoden take() und put(), die bei leerer / voller Queue blockieren– Für Erzeuger-Verbraucher Architekturen (z.B. Thread Pools)

• Neue ColIection Interfaces Deque und BlockingDeque (ab Java 6)– Deque steht für Double Ende QUEue– Für „Work Sharing“ und „Work Stealing“ Architekturen

26


Executor Framework (1)

• Ermöglicht asynchrones Ausführen von Tasks in Thread Pools– Trennung von Aufgabe (Task) und deren tatsächlicher Ausführung

• Task wird durch Interface Runnable beschrieben– Alter Bekannter aus JDK 1.0

• Keine Aussage wann oder wie Tasks ausgeführt wird (Execution)– Schnittstelle nötig für Taskübergabe zur Ausführung (Submission)


Executor Framework (2)

• Neues Interface Executor– Executor Objekte können Tasks zur Ausführung entgegen nehmen

• Konkrete Art der Ausführung von Implementierung abhängig

• Executor Implementierung bestimmt „Execution Policy“– Ressourcen Verwendung, Ausführungsreihenfolge, ...– Execution Policy leicht konfigurierbar je nach Hardware

27


Executor meets Runnable

• Executor Interface

public interface Executor {void execute(Runnable command);

}

• Runnable Interface

public interface Runnable {void run();

}


Neues Code Idiom

• Aus alt:

new Thread(myRunnable).start()

• Mach neu:

myExecutor.execute(myRunnable)

28


Woher nehmen? (1)

• Klasse ThreadPoolExecutor direkt instanziieren– Oder Subklasse ScheduledThreadPoolExecutor

• Utility Klasse Executors– Analogon zu Collections Klasse des Collection Frameworks

• Executors enthält diverse statische Factory Methoden– Leichtes Executor Erzeugen mit gängigen Voreinstellungen


Woher nehmen? (2)

• newFixedThreadPool(int nThreads)– Feste Größe, ersetzt unerwartet beendete Threads

• newCachedThreadPool()– Unbegrenzter Größe, wächst und schrumpft nach Bedarf

• newSingleThreadExecutor()– Ein Arbeitsthread, Tasks werden sequentiell abgearbeitet

• newScheduledThreadPool(int corePoolSize)– Für verzögerte und periodische Ausführung (Timer Ersatz)

29


Stets zu Diensten (1)

• Konkrete Executor Implementierung beeinflußt Anwendung– Executor kann z.B. neue Threads erzeugen

• Executor stellt Dienst (Service) für Anwendungen zur Verfügung

• Verwaltung über eigene Lifecycle Methoden wünschenswert– Dienste können gestartet und gestoppt werden


Stets zu Diensten (2)

• Eigenes Interface ExecutorService– Subinterface von Executor

• ExecutorService definiert Lifecycle– Drei Zustände: „Running“, „Shutting Down“ und „Terminated“

• Zustandswechsel durch entsprechende Methoden– shutdown(), shutdownNow(), awaitTermination(), ...

• Rückgabetyp der statischen Executors Factory Methoden– implementiert von ThreadPoolExecutor

30


Demo

Demo „ Concurrency Utilities“


Blick in die Zukunft (1)

• Task Abstraktion durch Runnable hat Schwächen– Keine Ergebnisrückgabe (nur Seiteneffekte), keine checked Exceptions

• Callable Interface für ergebnisbehaftete Tasks

public interface Callable<V> {V call() throws Exception;

}

• Callable Objekte ausführbar durch ExecutorService– submit() Methoden, geben Future Objekte zurück

public interface ExecutorService { // Auszug<T> Future<T> submit(Callable<T> task);

}

31


Blick in die Zukunft (2)

• Future beinhaltet Ergebnis eines asynchronen Aufrufs (Callable)– Ergebnis abfragbar durch Methode get()

• Future Interface enthält auch Lebenszyklus eines Tasks– Berechnung kann bei Zeitüberschreitung unterbrochen werden

public interface Future<V> { // AuszugV get() throws InterruptedException, ExecutionException;boolean cancel(boolean mayInterruptIfRunning);

}

• Runnable können in Callable Objekte umgewandelt werden– Util Methode callable() in Klasse Executors– Methode submit() in Interface ExecutorService ist für Runnable überladen– Klasse FutureTask kann Callable Objekte als Runnable wrappen


Sekunde…

• Wenn noch Zeit ist…

32


Das leidige Dokumentieren (1)

• Korrektes Verhalten einer Klasse ist definierbar (dokumentierbar)– Invarianten, Postconditions, Preconditions– Grundvoraussetzung für Aussagen über „Thread-Safety“

• „Thread-Safe“ Klasse impliziert mehrere Dinge– Konkurrierende Aufrufe beeinträchtigen korrektes Verhalten nicht– Synchronisierung unnötig durch Aufrufer

• Zwei Dokumentationsebenen (Schnittstelle vs. Implementierung)– Schnittstelle: Ist Locken durch Client möglich?, ...– Implementierung: Welche Locks schützen was?, ...

• Alles andere ist raten!


Das leidige Dokumentieren (2)

• Bisher keine definierte Art der Dokumentation– „[...] a class must [...] document in prose [its] level of thread safety [...]“

• Effective Java Item 52 „Document Thread Safety“– Taxonomie zur Dokumentation von Klassen– Immutable, T-safe, Conditionally T-safe, T-compatible, T-hostile

• Concurrency Annotations aus „Java Concurrency in Practice“– Klassen: @Immtuable, @ThreadSafe, @NotThreadSafe– Felder und Methoden: @GuardedBy(String lock)

• Bekanntestes Antibeispiel aus JDK Javadoc– SimpleDateFormat (bis einschließlich Java 1.3)

33


Lint Werkzeuge

• Werkzeug zur statischen Codeanalyse– Ursprünglich Kommandozeilentool aus der C Welt

• Alarmiert über verdächtige Sprachkonstrukte– Aber nicht zwangsläufig falsche Konstrukte

• Diverse Tools für Java verfügbar– FindBugs, PMD, Checkstyle, ...– JSR 305 „Annotations for Software Defect Detection“ (Einrichtung 2006)

• FindBugs besitzt eigene Kategorie „Multithreaded correctness“– Double-checked locking, Spin loops, Unreleased locks, ...– Prüft auch Concurrency Annotations („Java Concurrency in Practice“)


Testen (1)

• Concurrent Software ist schwerer testbar als sequentielle– Fehler nicht deterministisch und schwerer reproduzierbar

• Testcode ist ebenfalls Concurrent Software– Tests können Fehler im Anwendungscode maskieren

• Phänomen bekannt als „Heisenbug“– „A bug that disappears or alters its behavior when one attempts to

probe or isolate it.“ („http://www.jargon.org“)– Tests möglichst frei von Synchronisierung

34


Testen (2)

• Concurrent Bestandteile einer Anwendung isolieren– Häufig beschränkte Systemteile (Workflows, Pools, Queues, ...)– Oberstes Ziel ist isolierte Testbarkeit

• Fehler sind zufällige Ereignisse– Testlaufzeiten erhöhen– Zustandsraum (Ausgangszustände und Eingangsgrößen) variieren

• Prozessorzahl der Testplattform berücksichtigen– Zu wenig Threads verhindern Preemption und Thread-Interaktion– Faustregel: Mehr aktive Threads als Prozessoren


Immutability

• Bequeme Möglichkeiten Synchronisierung zu vermeiden– Daten auf einen Thread beschränken (Thread Confinement)– Unveränderliche Objekte verwenden (Immutability)

• Immutable Objekte...– können nach Erzeugung nicht verändert werden– geben „this“ Referenz nicht während der Erzeugung weiter– besitzen nur „final“ Felder (Initialization Safety)

35


Effectively immutable

• Objekte können „Effectively immutable“ sein– zustandsändernde Methoden nach Erzeugung nicht mehr aufrufen– aber Objekt Veröffentlichung muß sicher sein (Safe Publication)

• Objektreferenz werden sicher veröffentlicht in...– static initializer Blöcken– volatile Feldern bzw. AtomReference Objekten– final Feldern bei Erzeugung von Objekten– Lock geschützten Feldern

• Danach Verwendung als de facto immutable


Literaturhinweise

• Java Concurrency in PracticeSprache: EnglischBroschiert - 403 Seiten - Addison-Wesley LongmanErscheinungsdatum: 25. Mai 2006ISBN: 0321349601

• Concurrent Programming in JavaSprache: EnglischBroschiert - 411 Seiten - Addison-Wesley LongmanErscheinungsdatum: 31. Dezember 1999ISBN: 0201310090

• Effective Java. Programming Language Guide.Sprache: EnglischBroschiert - 252 Seiten - Addison WeselyErscheinungsdatum: 5. Juni 2001ISBN: 0201310058

36


Links

• Java 6 java.util.concurrent API Docs– http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html

• Doug Lea Homepage– http://gee.cs.oswego.edu/dl

• JSR 166 Homepage– http://jcp.org/en/jsr/detail?id=166

• The Free Lunch Is Over (Online Artikel)– http://www.gotw.ca/publications/concurrency-ddj.htm

• FindBugs Homepage– http://findbugs.sourceforge.net


(Effective Java, Item 30: „Know and use the libraries“)

If you remember one thing

„To summarize, don‘t reinvent the wheel.“

37




Vielen Dank für IhreAufmerksamkeit !


Papick Garcia Taboada

Software Architekt

Technologie-Scout

Beratung

Projekte

Training

38


Steffen Schluff

Beratung

Projekte

Training

Im a pogramar

Iam a programer

I'm a programor

I write code




? ???

?Noch Fragen…

39


) Akademie ) ) Beratung )

„Orientierung“ in Objekten

• Schulungen, Coaching, Weiterbildungsberatung, Train & Solve-Programme

• Methoden, Standards und Tools für die Entwicklung von offenen, unternehmens- weiten Systemen

• Schlüsselfertige Realisierung von Software• Unterstützung laufender Projekte• Pilot- und Migrationsprojekte

) Projekte )

Multithreading im Zeichen von Mehrkernprozessoren · must not attempt to start, stop, suspend, or...

Documents

Transcript of Multithreading im Zeichen von Mehrkernprozessoren · must not attempt to start, stop, suspend, or...