Parallel Computing?

Zitat von Saruman

Soweit ich weiß, ist es ja nicht damit getan, bei der Programmierung einfach auf Multi-Threading zu achten, oder?

Was heißt "einfach auf Multi-Threading achten"? Üblicherweise gilt auf jeden Fall, daß du explizit um Multithreading bitten mußt. Aber ja, nur weil du N Threads hast, läuft dein Programm nicht gleich um einen Faktor N schneller: Idealerweise sollten deine Threads prozessorlastig sein, weil die Speicherbandbreite recht schnell ausgeschöpft ist. Je weniger Kommunikation/Synchronisation/sonstige Abhängigkeiten, umso besser.

Zitat

-) Im Tuwis finde ich keine Lehrveranstaltung zu dem Thema, obwohl es doch zumindest eine Vertiefungs-LVA wert wäre

Das ist eines von vielen Themen, die Vertiefungs-LVAs wert wären, aber unsere Uni ist leider nun mal so...

Zitat

Da ich fürs erste aber auch noch recht viel C++ entwickeln werde, würde mich interessieren, wie ich dabei mehrere CPU-Cores ausnutzen kann.

Libraries, die den pthreads-Standard implementieren, sind glaub ich so ziemlich überall verfügbar; das ist vielleicht die beste Wahl zur Zeit. (Außer vielleicht Microsoft tut was anderes und hat vor, noch lange was anderes zu tun, und man ist sicher, daß man bestimmt immer explizit nur für Windows entwickeln wollen wird.)

Ich habe dieses Buch gelesen und ganz brauchbar gefunden, aber wenn man ein bissi herumsucht, werden andere enthusiastischer empfohlen. Auf amazon.de meint z.B. einer: "If you want to write code, get "Programming with POSIX Threads" by David Butenhof." Allerdings meint der auch, daß er es nach dem Nichols-Buch nicht geschafft hat, Programme zu schreiben; ich habe es aber geschafft.

Es gibt auch noch OpenMP, das in gewissen Hinsichten komfortabler ist, aber spezielle Compiler braucht. Ein coding standard dort, wo ich im Sommer gearbeitet habe, hat davon abgeraten, aber vielleicht ist es einen Blick wert. Ich weiß nicht viel darüber.

Edit: Naja, und MPI erwähne ich dann auch noch. Ist aber weniger für Multicore und mehr für echt verteilte Cluster und single program multiple data gedacht (sprich numerische Simulationen, unabhängige Bilder rendern könnte man damit sicher auch sehr fein).

Vielleicht interessiert dich Erlang. Ist eine funktionale Sprache, die sehr oft in Verbindung mit Mehrprozessorsystemen erwähnt wird.

Zitat von gelbasack

Vielleicht interessiert dich Erlang. Ist eine funktionale Sprache, die sehr oft in Verbindung mit Mehrprozessorsystemen erwähnt wird.

Erlang ist tatsächlich ein Traum was paralleles Computing betrifft und ebenso wenn es um verteilte Systeme geht. Erlang Prozesse sind extrem leichtgewichtig: 1 Millionen leere Prozesse auf und zumachen dauert auf meinem Rechner (Core Duo, 2GB) 1.58000 Mikrosekunden. Die Sprache macht es zudem extrem einfach, parallelen & wartbaren Code zu schreiben.

Das Erlang System kann das alles machen weil es auf einer puren funktionalen Programmiersprache basiert. Der Flaschenhals beim Mulithreading sind die Seiteneffekte: Sobald man einen Zustand hat, der über mehrere Prozesse geshared werden darf, wird paralleles Programmieren zu einer fehlerlastigen und extrem schwer zu
optimierenden Angelegenheit (hat Paulchen ja auch schon angesprochen). Das macht Threading in prozeduralen/objektorientierten Sprachen so kompliziert (Dining Philosopher). Weil es aber in puren funktionalen Sprachen keine Seiteneffekte gibt, wird das Parallelisieren viel einfacher.

Nehmen wir z.B. die Funktion "map", die es in fast jeder Sprache, die Higher Order Funktions unterstuetzt, in der Standardbibliothek gibt:

map(function(x){x*x},[1,2,3,4])  // => [1,4,9,16]

Weil es in einer puren funktionalen Programmiersprache keine Seiteneffekte gibt, kann sich ein Compiler sofort sicher sein, das die Reihenfolge der Aufrufe egal ist. Dadurch lässt sich jeder der 4 Funktionsaufrufe sofort in einem eigenen Prozess ausführen.

In Erlang ist der Code fuer ein paralleles map ca 20 Zeilen lang. In dem Buch Programming Erlang wird eine Implementierung fuer eine generische MapReduce Library in ca 30 Zeilen gezeigt. Dem Glasgow Haskell Compiler kannst Du mit einem switch anweisen, dass er Aufrufe wie map automatisch für Multiprozessorsysteme optimieren soll.

Ich kann also die Implementierung der Programmlogik von der Parallelisierung trennen.

Ich kann mir durchaus vorstellen, dass funktionale Programmiersprachen in den nächsten Jahren drastisch an Popularität gewinnen werden. Sicher kann man sich da natürlich nicht sein, aber das Momentum ist da: Es gibt ein großes Problem, eben das Skalieren in die Multiprozessor-Generation, für das sich funktionale Programmierung als Lösung anbietet. Es gibt den Hype (vor allem um das neue Erlang Buch) und es gibt auch die fetten Klötze in der Industrie die dahinterstehen. Zum Beispiel hat Microsoft angekündigt F# jetzt als Primaersprache neben C# und VB zu vermarkten, Fuer Java wird Scala gepusht, Google verwendet das Akteur Modell von Erlang in ihren Bibliotheken und promotet natürlich ihr mapreduce. Und natürlich spielt sich Ericsson jetzt als der Experte für Erlang und Hochverfuegbarkeitssysteme auf.

Wer sich fuer das Thema interessiert, dem kann ich das Buch Programming Erlang - Software for a Concurrent World empfehlen, sowie das Kapitel ueber Software Transactional Memory von Simon Peton Jones, das unter dem Namen "Beautiful Concurrency" in dem Buch Beautiful Code erschienen ist. In Beautiful Code findet sich zudem auch ein Kapitel über MapReduce (Da stehen ueberhaupt nur coole Sachen drinnen).

Von Simon Peyton Jones gibt es auch ein Video von seinem Vortrag ueber Software Transactional Memory bei der OSCON (Hier sind die Slides). Ausserdem gibt es von einem Schueler von SPJ ein sehr gutes Paper zum Thema: Parallel Functional Programming: An Introduction.

Und ein zweiteiliges Intro in Haskell gibt es von SPJ auch.

ich würde einfach mit der Theorie anfgangen:
http://www.amazon.com/Principles-Dis…98710410&sr=8-1

aber wenn du wirklich etwas praktisches willst, dann vielleicht die beiden wären hilfreich:
http://www.amazon.com/Modern-Multith…98712048&sr=1-2

http://www.amazon.com/Patterns-Paral…d_sim_b_title_6

parallelisierung bedeutet nicht nur einfach Thread Programming, sondern auch algorithmen zu finden die effizient parallelisierbar sind.

anscheinend ist z.b. mergesort für parallele rechner besser geeignet als quricksort (http://www.iti.fh-flensburg.de/lang/algorithm…eren/algoen.htm)

schöne grüße.

p.s. pthreads-win32 scheint ja ein wrapper zu sein. ich würde einfach die Win32 Native's nehmen, oder wenn du unter .net entwikelst schau dir mal die TPL - Thread Parallel Library an (http://msdn.microsoft.com/msdnmag/issues…ult.aspx?loc=de)

Zitat von Plantschkuh!

Das ist eines von vielen Themen, die Vertiefungs-LVAs wert wären, aber unsere Uni ist leider nun mal so...

schaut es bei den SElern auf diesem gebiet auch so traurig aus? ich glaube du studierst ja software engineering, oder? als technischer informatiker bin ich erst 2 mal mit threading in kontakt gekommen. das war allerdings auch freiwillig. einmal bei "echtzeitprogrammiersprachen" und davor einmal bei "SE Linux". bleibt die frage ob man als technischer informatiker pthreads gelernt haben sollte? ich meine "ja".

Zitat von graviton

p.s. pthreads-win32 scheint ja ein wrapper zu sein. ich würde einfach die Win32 Native's nehmen,

oehm ja, und warum genau? um kuenstlich an einem standard vorbei zu entwickeln oder um das programm moeglichst nicht portabel zu machen?

und hier noch ein beispiel was man mit pthreads nicht macht
http://code.google.com/p/koolkit/wiki/papercut

Zitat von Kampi

schaut es bei den SElern auf diesem gebiet auch so traurig aus?

Naja ueber pthreads hab ich jetzt noch nichts vertiefendes gehoert, allerdings ist das ja "nur" ein standard interface zur Kommunikation mit Threads. Ich bin mir nicht sicher, ob das wirklich auf der Uni gelehrt werden muss. Wenn man die Probleme beim parallel computing gelernt hat, kann man sich das Wissen ueber pthreads leicht selbst aneignen. Das theoretische Wissen gibt es in SE meiner Meinung nach schon: In fortgeschrittener funktionale Programmierung, in Betriebsysteme (hab ich allerdings auf der HU gemacht), in verteilte Systeme oder in Datenbanksysteme wird man schon ganz gut mit der Domaine vertraut gemacht finde ich.

Das einzige, was ich am Mag SE wirklich etwas traurig finde, ist der zu starke Fokus auf Serviceorientierte Architektur (SOA). Das ist schon gut zu wissen, wird aber in viel zu vielen LVAs durchgenommen. So nach dem Motto "Weil meine LVA noch nicht ENTERPRISE(tm) genug ist fuers Magisterstudium, pack ich einfach noch schnell ein paar Folien ueber SOA und WS-* Zeug wie SOAP/WSDL/BPEL mit dazu." Ich finde auch das Mag sollte nicht so (pseudo-)praxisorientiert sein: Das geht oft schief, weil die Profs halt in der Regel Theoretiker sind. Die sollen mich nicht krampfhaft auf die Arbeit im Grosskonzern vorbereiten, sondern mich lieber an dem Wissen teilhaben lassen, mit dem sie sich ausserhalb der Uni beschaeftigen. Knoop, Puntigam, Rauber machen das z.B. sehr gut vor.

ja a9bejo, da gebe ich dir recht, ich finde auch das basiswissen wichtiger. und wie du schon sagtest, das bekommt man doch im studium geliefert. verteilte systeme und betriebssysteme haben wir techniker ja auch. und wenn man dort die grundlagen und "gefahren" verstanden hat, sind beispielsweise pthreads nicht gerade neuland oder besonders schwer zu verstehen. man koennte sie vielleicht in "systemnahes progrogrammieren" mit aufnehmen, dort wuerden sie ganz gut passen finde ich. sonst sind wir uns glaube ich alle einig, dass das lehrangebot etwas aufgebessert gehoert, mir wuerden so viele interessante dinge einfallen die man auf der uni machen koennte, wo es nahezu null bis genau null angebot gibt. ich wuerde mir mehr veranstaltungen richtung "kernel programming" wuenschen, da ist ja nichts vorhanden. bekannt ist mir nur die "operating systems kernel programming" veranstaltung, die glaube ich gar nicht mehr existiert und auch nicht wirklich detailiert war. eine LVA in der man einfach mal ein simples kernel-modul schreibt, das waer ja schon mal was. in richtung gnu/linux faellt mir nur "technische praxis der computersysteme" ein und die ist ja wohl nur als schnelles/billiges freifach zu bezeichnen. aber das ist eigentlich ein anderes thema und schon viel zu weit offtopic.

Zitat von Kampi

oehm ja, und warum genau? um kuenstlich an einem standard vorbei zu entwickeln oder um das programm moeglichst nicht portabel zu machen?

und hier noch ein beispiel was man mit pthreads nicht macht
http://code.google.com/p/koolkit/wiki/papercut

weder, noch
ich bevorzuge im allgemein die Native's, da sie mehr flexibilität bieten.
und, wenn ich etwas neues lerne (z.b. concurrent oder parallel programming) dann brauche ich schon flexibilität, um mit der sachen einfacher herumspielen zu können. dazu ersparre ich auch eine gewisse zeit dieser standard zu lesen bzw. zu verstehen.
aber wie gesagt, das ist ja nur meine meinung. im prinzip jeder/jede macht wie er/sie das einfacher findet.

Zitat von Kampi

schaut es bei den SElern auf diesem gebiet auch so traurig aus? ich glaube du studierst ja software engineering, oder?

Nein, ich studiere CompInt und war im Bakk auch technischer Informatiker. Zusätzlich zum ganzen geforke in Sysprog wäre es sicher gut, auch mal Threads zu machen. Aber so ist halt unsere Uni, im Weltbild der Studienkommission kommen Informatiker offenbar nicht mit parallelen Systemen, scientific computing und Numerik in Berührung...

Zitat von a9bejo

Das theoretische Wissen gibt es in SE meiner Meinung nach schon: In fortgeschrittener funktionale Programmierung, in Betriebsysteme (hab ich allerdings auf der HU gemacht), in verteilte Systeme oder in Datenbanksysteme wird man schon ganz gut mit der Domaine vertraut gemacht finde ich.

Ich hab nicht alle diese LVAs gemacht, aber in fortgeschrittener Funkprog (vor einigen Jahren) und Betriebssysteme ist es nicht darum gegangen, wie man parallele Algorithmen entwickelt, Deadlockfreiheit sicherstellt, angemessene Tools verwendet etc. War es bei dir schon so? Das wäre ein Zeichen, daß sich was bessert.

Zitat von Plantschkuh!

Ich hab nicht alle diese LVAs gemacht, aber in fortgeschrittener Funkprog (vor einigen Jahren) und Betriebssysteme ist es nicht darum gegangen, wie man parallele Algorithmen entwickelt, Deadlockfreiheit sicherstellt, angemessene Tools verwendet etc. War es bei dir schon so? Das wäre ein Zeichen, daß sich was bessert.

Ich glaube viele von den Studenten, die sich auch in ihrer Freizeit (und oft auch im Beruf) mit Informatik beschäftigen (und ich glaube Kampi und die Planschkuh grasen auch auf dieser Weide), dann wirkt das, was man auf der Uni macht, oft oberflächlich. Aber ich finde diesen Vergleich unfair: Wenn ich mich leidenschaftlich 14 Tage lang in ein Thema vertiefe, das mich jetzt gerade interessiert, das ich in meinem eigenen Tempo lerne und wo ich mich an dem gesamten Expertenwissen aus dem Internet bedienen kann - Dann kann sowieso keine LVA da in einem Semester auch nur annähernd mithalten.

Was ich mir von der Uni erwarte sind Denkanstösse und Wegweiser in alle Himmelsrichtungen. Und was das betrifft bin ich an der TU eigentlich gar nicht so unzufrieden. Ausnahmen sind wie schon gesagt die (pseudo-)praxis orientierten Veranstaltungen. Ich meine es gibt schon überall Dinge die ich ändern würde. Aber ich glaube auch es gibt keine perfekten Systeme, sondern nur solche, die weniger scheiße sind als ihre Vorgänger. Und um das zu erreichen, braucht man schon sehr viel Glück.

Ich habe zum Beispiel in Betriebssysteme (wie schon gesagt auf der HU, bei Zima) Deadlocks durchgemacht und auch wie diese verhindert werden. Im Prinzip sind das einfach die Lösungen zum Dining Philosopher Problem.

In fortgeschrittener Funkprog wurde "Parallelism in Functional Languages" durchgenommen, das ich ja weiter oben schon in einem Post angesprochen habe. Da ging es um impliziten/explizite Parallelisierung und den Kompromiss zwischen den beiden, die Knoop "Algorithmic skeletons" nennt. Das sind, wie der Name vermuten laesst, eigentlich Patterns fuer parallele Algorithmen, und die meisten davon kommen vielen auch gleich bekannt vor wie (Farm, Map, Reduce, Branch&Bound, Divide&Conquer).

Das sind jetzt alles nicht die Super Vertiefungsveranstaltungen gewesen, in denen es nur um paralleles Programmieren geht. Aber wenn man alles zusammen nimmt, was im Studium so um das Thema herum erzaehlt wird, dann bekommt man, finde ich, einen ganz guten Überblick über die Problemstellungen in der parallelen Programmierung. Zum Beispiel die Kapitel über Synchronisation und Transaktionen im Datenbanksysteme Buch waren eine ganz hervorragende Vorbereitung für parallele Algorithmen. Wie z.B. das Modell des Software Transactional Memory (siehe das video-intro das ich oben gepostet hatte). Und auch die ganzen Webservice-LVAs tragen ihren Teil dazu bei.

Wie man mit Threads arbeitet, lernt man in verschiedenen Uebungen, wie beispielsweise verteilte Systeme oder den ganzen "bau mir mal ne Java App" LVAs. Wie gut ist eine andere Frage, und in systemnaher hätte ich auch gern etwas mehr darueber gehört, aber wenn man die Problematik erkannt hat, dann kann man sich die Praxis ja auch im Beruf besorgen. Und ehrlich gesagt will ich auf der Uni nicht mehr über Threading lernen: Threads sind meiner bescheidenen Meinung nach der Flaschenhals bei der parallelen Programmierung, und wir sollten schauen, das wir uns von diesem Mist so schnell wie nur möglich trennen. Am besten noch vor dem nächsten Jahrzehnt.

Zitat von a9bejo

Ich habe zum Beispiel in Betriebssysteme (wie schon gesagt auf der HU, bei Zima) Deadlocks durchgemacht und auch wie diese verhindert werden. Im Prinzip sind das einfach die Lösungen zum Dining Philosopher Problem.

Mit Verlaub, "... requires that the philosophers communicate ...", "... arbitrate and prevent deadlock ..." und "... not always practical, especially when the list of required resources is not completely known in advance ..." klingt nicht so, als ob auch nur das Dining Philosopher Problem allgemein gelöst wäre, von anderen Synchronisationsproblemen ganz zu schweigen. Es gilt mal wieder: Patterns sind nett, aber auch wenn du einen Hammer hast, ist nicht alles ein Nagel.

Zitat

Da ging es um impliziten/explizite Parallelisierung und den Kompromiss zwischen den beiden, die Knoop "Algorithmic skeletons" nennt.

Gutgut. Wie gesagt, war bei mir damals noch nicht drin.

Zitat

Threads sind meiner bescheidenen Meinung nach der Flaschenhals bei der parallelen Programmierung, und wir sollten schauen, das wir uns von diesem Mist so schnell wie nur möglich trennen. Am besten noch vor dem nächsten Jahrzehnt.

Threads sind überhaupt kein Problem, shared state ist das Problem. Ja, es wäre toll, bessere Libraries für Message Passing zu haben. MPI kann was, ist aber auch grausiger als die Messages von Erlang.

Zitat von Plantschkuh!

klingt nicht so, als ob auch nur das Dining Philosopher Problem allgemein gelöst wäre, von anderen Synchronisationsproblemen ganz zu schweigen.

Hab ich doch auch gar nicht behauptet. Ich hab nur gesagt das das deadlock problem im Prinzip die gleiche Problemstellung ist. Nagut - ich hab 'Loesungen' anstatt 'Loesungsansaetze' geschrieben. Aber sich daran aufzuhaengen ist etwas pedantisch.

Zitat von Plantschkuh!

Es gilt mal wieder: Patterns sind nett, aber auch wenn du einen Hammer hast, ist nicht alles ein Nagel.

Stimmt. Hab ich was anderes behauptet?

Zitat von Plantschkuh!

Threads sind überhaupt kein Problem, shared state ist das Problem.

Wie so oft unterscheiden sich unsere Meinungen praktisch nur durch die Terminologie: Der shared state ist fuer mich der wesentliche Unterschied zwischen Thread und Prozess ("different threads of the same process share some resources while different processes do not", WP). In Erlang/Haskell wird deshalb immer von Prozessen gesprochen.

Zitat von a9bejo

Aber sich daran aufzuhaengen ist etwas pedantisch.

Hmm. Der ganze Absatz hat für mich geklungen nach "ach, Synchronisationsprobleme jeder Art sind einfach Instanzen des Dining-Philosopher-Patterns, und das ist ist trivial, und es gibt massig Lösungen". Wenns nicht so gemeint war, OK.

Zitat

Wie so oft unterscheiden sich unsere Meinungen praktisch nur durch die Terminologie: Der shared state ist fuer mich der wesentliche Unterschied zwischen Thread und Prozess ("different threads of the same process share some resources while different processes do not", WP). In Erlang/Haskell wird deshalb immer von Prozessen gesprochen.

Wenn ich in C mit pthreads eine pure Funktion in einem neuen Thread starte, ist das dann ein Prozess? Wenn ich in Erlang eine impure Funktion in einem neuen Prozess starte, ist das dann ein Thread?

Ich glaube, wir meinen schon das selbe, aber C mit einer Thread-Library, die Erlang-ähnliche Message-Primitive bereitstellt, wäre nicht weniger sauber oder zuverlässig als Erlang. In beiden hat der Programmierer die Möglichkeit, sich in den Fuß zu schießen, und in beiden muß er mitdenken, um das zu vermeiden. (Erlang hat den gewissen Vorteil beim Komfort, daß Datenstrukturen automatisch quasi "const" sind, und daß umständliche Speicherallokationen hinter der Termsyntax versteckt sind.)

Zitat von Plantschkuh!

Hmm. Der ganze Absatz hat für mich geklungen nach "ach, Synchronisationsprobleme jeder Art sind einfach Instanzen des Dining-Philosopher-Patterns, und das ist ist trivial, und es gibt massig Lösungen". Wenns nicht so gemeint war, OK.

Nein, so war es wirklich nicht gemeint (Aber beim nochmaligen Durchlesen versteh ich das Du es so interpretiert hast). Ich wollte eigentlich nur nicht den falschen Eindruck hinterlassen, dass wir im Detail durchgesprochen haetten, wie z.B. unter Unix Deadlocks verhindert werden. Wir haben uns zwar schon auch die konkreten Faelle (Unix und WinNT) angeschaut, aber vor allem haben wir dort eben Dining Philospher gemacht. Ich sehe Dining Philosopher für Deadlocks ca so wie das ISO/OSI Modell für Netzwerkverkehr: Ganz so spielt es sich in der Realität nicht ab, aber es ist sehr gut geeignet, um die Probleme und die Lösungsansätze zu erklären.

Zitat von Plantschkuh!

Wenn ich in C mit pthreads eine pure Funktion in einem neuen Thread starte, ist das dann ein Prozess? Wenn ich in Erlang eine impure Funktion in einem neuen Prozess starte, ist das dann ein Thread?

Also zumindest was mich betrifft: Ja.

Zitat von Plantschkuh!

Ich glaube, wir meinen schon das selbe, aber C mit einer Thread-Library, die Erlang-ähnliche Message-Primitive bereitstellt, wäre nicht weniger sauber oder zuverlässig als Erlang. In beiden hat der Programmierer die Möglichkeit, sich in den Fuß zu schießen, und in beiden muß er mitdenken, um das zu vermeiden. (Erlang hat den gewissen Vorteil beim Komfort, daß Datenstrukturen automatisch quasi "const" sind, und daß umständliche Speicherallokationen hinter der Termsyntax versteckt sind.)

Stimme dir wieder zu. Aber wie müsste denn dann so eine Biliothek aussehen?

Man müsste sicherstellen, das Funktionen keine Seiteneffekte haben, und zwar so das ein für paralleles Computing optimierter Compiler sich darauf verlassen kann. Man müsste Abstraktionen schaffen, um Prozesse genauso natürlich zu erstellen wie if Anweisungen, und man müsste die Prozesse so leichtgewichtig machen, das man damit verschwenderisch umgehen kann.

Ich stimme dir völlig zu, und solche in C geschriebenen Bibliotheken gibt es heute bereits: Nämlich Erlang und den Glasgow Haskell Compiler. Beides sind Implementierungen für die notwendigen Abstraktionslayer und die Termsyntax und die Message-Primitive, die wir beide angesprochen haben.

PS: Ein frohes neues Jahr wuensche ich!

Zitat von a9bejo

Stimme dir wieder zu. Aber wie müsste denn dann so eine Biliothek aussehen?

In C notwendigerweise umständlich Aber im Prinzip ist es möglich, mit ein paar Funktionen, die pthreads o.ä. verwenden, die paar Primitive von Erlang (spawn, send, receive) einigermaßen nachzubauen. Messages wären wohl Arrays von unsigned char oder so, die der User packen und entpacken müßte. Für Systeme, die über mehrere Rechner verteilt sind, braucht man natürlich noch was anderes zusätzlich zu pthreads, aber PIDs hinter abstrakten Datentypen kapseln, das ist nicht so schwer.

Zitat

Man müsste sicherstellen, das Funktionen keine Seiteneffekte haben, und zwar so das ein für paralleles Computing optimierter Compiler sich darauf verlassen kann.

Muß man nicht unbedingt, Erlang verlangt das ja auch nicht. Es wäre für den Programmierer wohl eine Hilfe, wenn einige grundlegende Eigenschaften statisch geprüft werden (alle Pointerargumente sind const, keine Verwendung von globalen Variablen), aber das und viel mehr geht eh mit vorhandener Technologie.

Zitat

PS: Ein frohes neues Jahr wuensche ich!

Danke, ebenfalls. Ich freue mich auf viele kontroverse Diskussionen auch in diesem Jahr

Zu pthread-win32 kann ich nur sagen: Klasse. Ist relativ einfach zu handhaben. Hängt von dem Anwendungsgebiet ab.

Die Natives bieten kaum Flexibilität, zumindestens wenn du es auf andere Betriebssysteme protieren willst. Mit pthread brauchst du zumindestens unter Unix/Linux( auch Mac) nichts am pthread-Code ändern.

OpenMP ist auch eine gute Wahl. Soweit ich aber weiß ist OpenMP aber auch vorrangig fürs Clustering gedacht oder? Man kann natürlich auch für ein System entwicklen, das coole der Weg zum Clustered-Execution ist dann "nicht mehr weit".

mfg Schakal