File encryption multithreading

[cryptor]

Aber wenn jetzt 4 Threads auf den gleichen Code(algorithmus) zur gleichen Zeit zugreifen brauche ich doch eine Synchronisation, damit dies nicht passiert!? oder?

[CStoll]

Für den Code/Algorithmus brauchst du keine Synchronisation, der kann sich nicht ändern (ich gehe mal davon aus, daß du keine selbstmodifizierenden Programme geschrieben hast). Synchronisieren mußt du nur, wenn mehrere Threads auf die selben Daten zugreifen wollen.

[cryptor]

Ja aber wenn ich in :

nur zum bsp.:

dannmmuss doch hier synchronisiert werden oder?
Weil plaintext - ciphertext - len sind ja auch Daten!

algo(__in plaintext ,__out ciphertext ,len);

[Martin Richter]

Deshlab sage ich doch.
Wenn jeder Thread einen eigenen Abschnitt kodiert (sofern das der Algoritmus zulässt), sind die Daten nicht shared!

Zudem was soll der Quatsch: Wenn Deine Daten als ganzes geschützt werden müssten, kannst Du Multithreading voll vergessen. Dann ist ein Thread viel schneller.

[CStoll]

Das kommt darauf an, wer noch parallel zu dem Verschlüsselungs-Thread auf diese Daten zugreifen kann. Drüben im C++ Board gibt es schon eine umfangreiche Diskussion zur Frage, wann Synchronisation nötig ist.

Ansonsten solltest du dir eventuell überlegen, ob dein Algorithmus überhaupt sinnvoll in parallele Teile zerlegt werden kann. Bei manchen Verfahren dürfte es schwierig bis unmöglich sein, unabhängige Teilalgorithmen zu isolieren.

[cryptor]

Sagen wir ich teile die arbeit unter den jeweillgen threads auf.
Also thread1 hat zbsp. 5 files, thread2 5, und thread3 4.
Dann müsste ich synchronisieren. Weil ja thread 1,2,3 ja gleichzeitig auf die funk. algo(__in plaintext ,__out ciphertext ,len); zugreiffen könnten. habe ich das richtig verstanden! Denke ja. Aber dann ist ja genau bei der synchronisation der Flaschenhals! Ist das den schneller dadurch? oder macht hier die sync nicht so viel aus? Weil jeder Thread muss doch auf den anderen warten bevor er an die Reihe kommt!?

Wie ist es dann mit sync des Mode stat zbsp. CBC? den der algo läuft ja unter einem mode!?

[CStoll]

Nochmal: Daß die Threads gleichzeitig diese Funktion aufrufen, stört überhaupt nicht (außer du verwendest statische Variablen, aber dann hast du ganz andere Probleme). Du übergibst bei jedem Funktionsaufruf ein eigenes plaintext/ciphertext-Paar, das heißt, daß jeder Thread auf anderen Daten arbeitet - das heißt du brauchst auch keine Synchronisation.
(darum, welher Thread wann an die Reihe kommt zu rechnen, kümmert sich schon dr Scheduler deines Rechners)

[cryptor]

Ich habe es wohl nicht richtig verstanden.
Warum muss den hier sync. werden??? http://msdn.microsoft.com/en-us/library/ms686927(v=vs.85).aspx

[Wutz]

Mit halbwegs gutem Threadpooling bringt das was für dateiweise Abarbeitung, selbst auf einer Festplatte. Bei einem 4 Core durchaus >50% Auslastung, ich habe dies in einem anderen dateiweisen Anwendungsfall als encryption ausprobiert.
Synchronisierung braucht man dabei selbstverständlich nicht (wenn der Threadcode sauber gekapselt ist).

[CStoll]

ERstens zu Demonstationszwecken und zweitens weil hier alle Threads auf eine gemeinsame Resource zugreifen - die Ausgaben gehen alle nach stdout (und der C-Standard spezifiert nichts zur Thread-Sicherheit der Standardbiobliothek, also könnte es Probleme geben, wenn zwei Threads gleichzeitig printf() aufrufen).

[cryptor]

CStoll schrieb:

ERstens zu Demonstationszwecken und zweitens weil hier alle Threads auf eine gemeinsame Resource zugreifen - die Ausgaben gehen alle nach stdout (und der C-Standard spezifiert nichts zur Thread-Sicherheit der Standardbiobliothek, also könnte es Probleme geben, wenn zwei Threads gleichzeitig printf() aufrufen).

Danke!

[cryptor]

Aber wer sagt mir dann das der Algo thread-safe ist? Wenn es die STD C-Library nicht ist.

[Jochen Kalmbach]

CStoll schrieb:

Erstens zu Demonstationszwecken und zweitens weil hier alle Threads auf eine gemeinsame Resource zugreifen - die Ausgaben gehen alle nach stdout (und der C-Standard spezifiert nichts zur Thread-Sicherheit der Standardbiobliothek, also könnte es Probleme geben, wenn zwei Threads gleichzeitig printf() aufrufen).

Bitte????

Seit VS2005 gibt es keine CRT mehr, welche *nicht* Thread-Safe ist!
Schau einfach mal nach in Deinen Projekteinstelungen: C/C++|Code Generation|Runtime Library "Multithreaded (DLL) (Debug)".

OT: Was ist denn heute mit Dir (mir) los???

[Wutz]

CStoll schrieb:

ERstens zu Demonstationszwecken und zweitens weil hier alle Threads auf eine gemeinsame Resource zugreifen - die Ausgaben gehen alle nach stdout (und der C-Standard spezifiert nichts zur Thread-Sicherheit der Standardbiobliothek, also könnte es Probleme geben, wenn zwei Threads gleichzeitig printf() aufrufen).

Wer prozessweit oder gar systemweit (stdout) eindeutige Daten in Multithreads verwendet, ist auch selbst schuld.
Für die Kapselung eigener (globaler) Daten bieten diverse Multithreadbibliotheken Geeignetes an.

[cryptor]

Ja was jetzt? Ich bin doch recht verwirrt! Scheinbar weis das niemand so genau!?
Wenn ich das bsp. von der MSDN ausfüre funktioniert es. Sobald ich aber die mutex sachen weg nehme. ist undefiniertes verhalten angesagt! Also die threads kommen sich bei der ausgabe in die Quere!!! Ja was jetz?! ist nun die STD C-Lib threadsafe oder nicht? Und könnte mir mal einer erklären wan genau sync. werden muss und wann nicht?

Wer sagt das der Algo threadsafe ist?

[Wutz]

Jochen Kalmbach schrieb:

Seit VS2005 gibt es keine CRT mehr, welche *nicht* Thread-Safe ist!

Ach so?
Wozu gibt es dann die *_s Funktionen, wenn doch immer und überall und mit allen möglichen Einstellungen alles immer threadsafe ist?

http://msdn.microsoft.com/de-de/library/abx4dbyh%28v=vs.80%29.aspx

[Jochen Kalmbach]

*_s heisst nicht "thread sicher" sondern "secure". Da in diesen Methoden mehr prüfungen bzgl. Buffer-Überläufe gemacht werden!

In der CRT sind *alle* Methoden threadsicher, ausßer diese die speziell dafür markiert sind (*_nolock) wie z.B. write_nolock
http://msdn.microsoft.com/en-us/library/eadhs8bd.aspx

DIe CRT ist Thread safe... aber wenn Du z.B. sowas machst:

Thread 1:
printf("Hallo");
printf("Welt");

Thread 2:
printf("...");

Dann kann Dir niemand sagen in welcher Reihenfolge es ausgegeben wird... es ist also Folgendes möglich:
HalloWelt...
Hallo...Welt
...HalloWelt

[CStoll]

Jochen Kalmbach schrieb:

CStoll schrieb:

Erstens zu Demonstationszwecken und zweitens weil hier alle Threads auf eine gemeinsame Resource zugreifen - die Ausgaben gehen alle nach stdout (und der C-Standard spezifiert nichts zur Thread-Sicherheit der Standardbiobliothek, also könnte es Probleme geben, wenn zwei Threads gleichzeitig printf() aufrufen).

Bitte????

Seit VS2005 gibt es keine CRT mehr, welche *nicht* Thread-Safe ist!
Schau einfach mal nach in Deinen Projekteinstelungen: C/C++|Code Generation|Runtime Library "Multithreaded (DLL) (Debug)".

das wird schwierig ohne eine funktionsfähige Entwicklungsumgebung

Und selbst wenn die printf()-Aufrufe threadsicher sind, gilt immer noch der "Erstens"-Teil.

OT: Was ist denn heute mit Dir (mir) los???

Keine Ahnung. Wenn ich es nicht besser wüßte, würde ich sagen daß einer von uns Streit sucht

@cryptor: Um zu wissen, ob der Algorithmus sicher ist, müsstest du ihn von innen betrachten (oder in seiner Dokumentation nachsehen). Aber bei Verschlüsselungsalgorithmen hast du vermutlich ganz andere Probleme, wenn sie während ihrer Arbeit irgendwelche threadübergreifend gültigen Daten (außer der Ein- und Ausgabe) manipulieren.

[cryptor]

Jochen Kalmbach schrieb:

*_s heisst nicht "thread sicher" sondern "secure". Da in diesen Methoden mehr prüfungen bzgl. Buffer-Überläufe gemacht werden!

In der CRT sind *alle* Methoden threadsicher, ausßer diese die speziell dafür markiert sind (*_nolock) wie z.B. write_nolock
http://msdn.microsoft.com/en-us/library/eadhs8bd.aspx

DIe CRT ist Thread safe... aber wenn Du z.B. sowas machst:

Thread 1:
printf("Hallo");
printf("Welt");

Thread 2:
printf("...");

Dann kann Dir niemand sagen in welcher Reihenfolge es ausgegeben wird... es ist also Folgendes möglich:
HalloWelt...
Hallo...Welt
...HalloWelt

Okey, doch warum ist es bei printf() anders?

[Jochen Kalmbach]

Wie meinst Du das? Anders als WO?
printf ist hier wunderbar thread safe...