File encryption multithreading

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!

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.

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.

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

Ja wegen der Ausgabe! Deswegen ist sie ja nicht thread-safe oder?

Ich möcht hier nicht herumspamen. Möchte es einfach verstehen!
Also nocheinmal für ein anfänger, wann ist es oder besser wann muss man eine sync machen zbsp. mit createmutex & waitforsingleobject??

CStoll

Du brauchst Synchronisation, wenn du auf Daten zugreifst, die von mehreren/anderen Threads verändert werden können (globale Objekte, statische Variablen, etc).

Was das printf() dort oben angeht, da ist anscheinend jeder Aufruf für sich thread-sicher, eine Folge aus mehreren unabhängigen Aufrufen jedoch nicht.

CStoll schrieb:

Du brauchst Synchronisation, wenn du auf Daten zugreifst, die von mehreren/anderen Threads verändert werden können (globale Objekte, statische Variablen, etc).

Was das printf() dort oben angeht, da ist anscheinend jeder Aufruf für sich thread-sicher, eine Folge aus mehreren unabhängigen Aufrufen jedoch nicht.

Genau das. Doch ich möchte noch ein bisschen definierter, was heisst DATEN genau?

char array[100] ?
int var; ?
File *ptr = NULL; ?

CStoll

So ziemlich jede Variable enthält Daten. Allerdings sind wohl die meisten Variablen lokal und damit außerhalb der Reichweit anderer Threads.

Jetzt verstehe ich was Du meintest! Danke für deine mühe!