pthread_mutex_t - Ein "Master-lock"?

[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.