pthread_mutex_t - Ein "Master-lock"?

[simbad]

Nochmal: Man gibt nicht jedem thread einen Mutex. Sondern "alle" threads teilen sich einen Mutex.

Wenn der Zeitpunkt der Veränderung für die Rechenthreads egal ist, dann kannst du das mit spinlocks machen.

Immer wenn geschrieben wird wird ein lock gemacht und danach ein unlock.

Und wenn dann die Worker-Threads die Variable nur zu wenigen Zeitpunkten kopieren, dann machen die das genause.

Aber nur ein Mutex/spinlock für alle.

[simbad]

manni66 schrieb:

Dein Problem ist nur sehr vage beschrieben. Wenn sich die Rechenthreads am Anfang eine Kopie der Variablen machen können, wäre std::atomic oder boost::atomic vielleicht eine Lösung.

Ich würde dir auf jeden Fall raten, C++11 oder boost Threads zu verwenden, wenn das möglich ist. Pthreads sind ein Systemspezifisches C-API.

pthreads, POSIX Threads, Portable Operating System Interface: Wo ist das systemspezifisch?
Es ist wohl davon abhängig ob ein Betriebssystem das unterstützt. Das ist aber bei C++11 nicht anders. Da isses davon abhängig ob der Compiler das unterstützt. Und boost ist eine eigene Library Collection. Mindestens genauso systemspezifisch wie pthreads oder C++ threads.

Es gibt viele Lösungen für das Problem. Wichtig ist das während des schreibenden Updates der Variable keiner von dort liest.

[Nathan]

simbad schrieb:

pthreads, POSIX Threads, Portable Operating System Interface: Wo ist das systemspezifisch?
Es ist wohl davon abhängig ob ein Betriebssystem das unterstützt.

Das ist die Definition von systemspezifisch.

Das ist aber bei C++11 nicht anders. Da isses davon abhängig ob der Compiler das unterstützt.

Jein. Es ist zwar davon abhängig ob es ein Compiler unterstützt. Im Gegensatz zu POSIX wird das jedoch in der Zukunft jeder C++ Compiler unterstützen.

Und boost ist eine eigene Library Collection. Mindestens genauso systemspezifisch wie pthreads oder C++ threads.

Nein, boost hält sich an den C++ Standard und bietet Support für viele verschiedene Betriebssysteme, indem sie immer die entsprechende native API des OS verwenden.

[Ethon]

Verwende boost::shared_mutex
Dann blockieren sich die Leser nicht.

[simbad]

Nathan schrieb:

simbad schrieb:

pthreads, POSIX Threads, Portable Operating System Interface: Wo ist das systemspezifisch?
Es ist wohl davon abhängig ob ein Betriebssystem das unterstützt.

Das ist die Definition von systemspezifisch.

Nö. POSIX beschreibt einmal das Interface und natürlich das zu erwartende Verhalten. Das ist bei strlen() oder strcpy() auch nicht anders. Die Verwendung von pthreads bedeutet lediglich das man die durch POSIX definierten interfaces bedient. Sie sind somit vom Betriebssystem unabhängig, da es grundsätzlich egal ist wie die API eines beliebigen OS die entsprechenden Funktionen benennt.
Mutex/Thread/Event und vieles mehr sind Bestandteil eines jeden modernen OS. Nur die API ist jedesmal anders. Da setzt POSIX mit der Standardisierung des Interface an.

Das ist aber bei C++11 nicht anders. Da isses davon abhängig ob der Compiler das unterstützt.

Jein. Es ist zwar davon abhängig ob es ein Compiler unterstützt. Im Gegensatz zu POSIX wird das jedoch in der Zukunft jeder C++ Compiler unterstützen.

In Zukunft sicher. Nur ist es ein Frage wie weit in die Zukunft es noch gehen muss bis es soweit ist.
Ich entwickel viel im embedded Bereich. Da fängt man langsam mit dem Sprung von C->C++ an. Und die Compilerbauer sind noch weit C++11 entfernt.

Und boost ist eine eigene Library Collection. Mindestens genauso systemspezifisch wie pthreads oder C++ threads.

Nein, boost hält sich an den C++ Standard und bietet Support für viele verschiedene Betriebssysteme, indem sie immer die entsprechende native API des OS verwenden.

Damit ist boost auch nur ein Wrapper. Denn boost ändert nicht das verhalten des Compilers. Es ist auch nicht möglich einen Compiler der nicht C++11 konform ist durch Verwendung von boost libraries in einen Compiler zu verwandeln der sich plötzlich C++11 konform ist, das nur zu deiner Argumentation bezüglich "hält sich an den C++ standard".
Ich habe schon Thread und Mutex und Event Klassen gebaut die auf die native API aufsetzen und das sich unter Linux und Windows gleich verhält. Damit habe ich mir aber lediglich ein einheitliches Interface für meine Anwendungen geschaffen. Das macht es aber alles nicht besser oder C++ Standard konformer.

[Belli]

Für Windows gibts hier eine Lösung für das Problem:
http://www.codeproject.com/Articles/16411/Ultra-simple-C-Read-Write-Lock-Class-for-Windows

[posix]

Schlanke Leser/Schreibersperren sind die Lösung!

http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx

[oenone]

posix schrieb:

Schlanke Leser/Schreibersperren sind die Lösung!

http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx

FTFY:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx

[Ethon]

simbad schrieb:

In Zukunft sicher. Nur ist es ein Frage wie weit in die Zukunft es noch gehen muss bis es soweit ist.
Ich entwickel viel im embedded Bereich. Da fängt man langsam mit dem Sprung von C->C++ an. Und die Compilerbauer sind noch weit C++11 entfernt.

Von was redest du? Gängige Compiler können alle C++11.

[tntnet]

Was Du suchst ist ein read-write-lock. Siehe pthread_rwlock_init und Konsorten.

[simbad]

Ethon schrieb:

simbad schrieb:

In Zukunft sicher. Nur ist es ein Frage wie weit in die Zukunft es noch gehen muss bis es soweit ist.
Ich entwickel viel im embedded Bereich. Da fängt man langsam mit dem Sprung von C->C++ an. Und die Compilerbauer sind noch weit C++11 entfernt.

Von was redest du? Gängige Compiler können alle C++11.

Was sind denn gängige Compiler? Ich rede vom embedded Software Entwicklung. Da findet man CPUs von Freescale zum Beispiel S12Z und PowerPC und Konsorten.
Das ist ein Gebiet in dem sich C++ erst langsam bis garnicht durchsetzt, obwohl ich das schon das eine oder andere mal vermisst habe.

[Ethon]

Ja und auch auf solchen Plattformen kann man clang oder gcc verwenden. Beide Compiler haben Backends für praktisch jede erdenkliche Architektur bzw die wenigsten Features haben Einfluss darauf was das Backend wirklich in Maschinencode gießen muss. Was das Frontend macht ist ja egal.

[simbad]

Ethon schrieb:

Ja und auch auf solchen Plattformen kann man clang oder gcc verwenden. Beide Compiler haben Backends für praktisch jede erdenkliche Architektur bzw die wenigsten Features haben Einfluss darauf was das Backend wirklich in Maschinencode gießen muss. Was das Frontend macht ist ja egal.

In der Industrie werden aber gcc und clang nicht immer eingesetzt. Gerade wenn Software nach ASIL entwickelt wird.

Hinzukommt das ich bei einem kommerziellen Compilerbauer zwar hohe Kosten habe, weil die halt richtig zulangen, aber dafür innerhalb von wenigen Tagen auch Bugfixes bekomme und das dann kostenfrei.
Ich muss also nicht erst Compilerbau studieren oder jemanden einstellen der den gcc/clang debuggen kann wenn der mal was nicht so macht wie er soll.

Dabei ist von der Risikobetrachtung für ein Projekt unerheblich das die Bug-Listen des gcc vielleicht klein sind. Wenn dann in der Erfolgsgeschichte sowas wie der gcc-4.9.0 auftaucht ist das Teil für lange Zeit in der Industrie gelaufen.

Wenn dem Projektmanager ein Fehler im Compiler gemeldet wird dann muss er auch einen definierten Zeitrahmen kennen bis wann das beseitigt ist.

[Ethon]

Diese Meta-Probleme bezüglich potentiell unausgereifter Software kann ich zwar irgendwo verstehen aber naja. Wir verwenden auf der Arbeit sogar early releases.
Aber halt Java.
Bezweifle dass jede Firma so an Dinosauriern hängt.

Im Endeffekt ist es halt so dass spätestens ab der Erzeugung von Zwischencode praktisch kein Unterschied mehr zwischen C, C++03 und C++11 bestehen sollte.
Ist ja gerade der Sinn davon - man möchte Optimierungen und Codegenerierung sprachunabhängig durchführen.

Clang erzeugt LLVM IR. Die LLVM selbst ist sehr gut getestet & stabil. Beim Clang selbst kann man im Zweifelsfall einfach eine alte Version nehmen. Wobei das Frontend mMn. weniger falsch machen kann. Wenn der Parser Macken hat dann bekommt man das sowieso direkt in Form von Compilerfehlern zu spüren. Ähnliches gilt für die semantische Analyse.

[simbad]

Ich wollte nur mal darauf hinweisen das es eben nicht in jeder Umgebung C++11 gibt. Das nicht in jedem Umfeld gcc/clang Verwendung findet, aus den unterschiedlichsten Gründen.

Für das vom Threadersteller beschrieben Problem isses einfach egal ob er pthreads, boost, WinAPI oder C++11 benutzt. Wichtig ist das er beim schreiben locked und vor allem nur einen Mutex, whatever, benutzt um die Zugriffe zu synchronisieren.
Er kann theoretisch auch unsynchronisiert arbeiten. Wird dann aber wahrscheinlich das eine oder andere mal ein Haufen Schrott rauskommen. Wenn er effektiv den Schrott erkennen kann, braucht er keine Synchronisation.

Wir wechseln während der Entwicklung nach Möglichkeit keine Compiler mehr aus. Die werden am Anfang auf den aktuellsten Stand gebracht und werden dann bis zum Ende verwendet, mit Ausnahme von Bugfixes.
Ist aber auch von Projekt zu Projekt anders.

[manni66]

simbad schrieb:

Für das vom Threadersteller beschrieben Problem isses einfach egal ob er pthreads, boost, WinAPI oder C++11 benutzt.

Selbstverständlich ist es für die konkrete Fragestellung egal. Genauso selbstverständlich sollte man in einem C++ Projekt kein C-API einsetzen, wenn man die Aufgabe mit Sprachmitteln oder einer C++ Bibliothek lösen kann. Beim Fragesteller wird das höchstwahrscheinlich der Fall sein.

[simbad]

manni66 schrieb:

simbad schrieb:

Für das vom Threadersteller beschrieben Problem isses einfach egal ob er pthreads, boost, WinAPI oder C++11 benutzt.

Selbstverständlich ist es für die konkrete Fragestellung egal. Genauso selbstverständlich sollte man in einem C++ Projekt kein C-API einsetzen, wenn man die Aufgabe mit Sprachmitteln oder einer C++ Bibliothek lösen kann. Beim Fragesteller wird das höchstwahrscheinlich der Fall sein.

Die Programmiersprache C++ ist an vielen Stellen so definiert worden das man sehr wohl C Funktionen einfach so verwenden kann. Umsonst gibt es die header files cstdio, cstring, cctype etc. wohl nicht.
Die Fixe Idee keine C-Funktionen in einem C++ Projekt zu verwenden ist schlicht eine Frage des persönlichen Geschmacks. Es gibt aber keinen technischen oder im Standard der Sprache versteckten Grund die C-Funktionen zu verschmähen wenn sie denn die geforderte Aufgabe erfüllen.
Das man bei den IO funktionen ein wenig vorsichtiger sein muss liegt an einem unter Umständen konkurrierenden Umgang mit resourcen. Die Verwendung von iostreams und printf in einem Programm sollte man tunlichst unterlassen.

Es ist durchaus nicht unüblich C Programme mit einem C++ Compiler zu übersetzen um von der besseren Typsicherheit zu profitieren. Und es ist auch völlig unproblematisch.