Mutex-frage
-
Gibt es irgendwelche negative Änderungen des Betriebssystem wenn gleichzeitig mehrere Mutexe einem Prozess angehören?
Mit freundlichen Grüßen in voraus und darauf freundlich hinweisend, dass ich mit "mehreren" ca. sechshunderttausend meine,
Rhombicosidodecahderon
-
Klar. Guck mal im DDK, da steht da alles drin ("Introduction to Mutex Objects")
Soweit ich weiß wird nämlich pro Mutex ein Thread erstellt, was bei 600k Mutexes doch recht dumm wird
-
Rhombicosidodecahedron schrieb:
Gibt es irgendwelche negative Änderungen des Betriebssystem wenn gleichzeitig mehrere Mutexe einem Prozess angehören?
Mit freundlichen Grüßen in voraus und darauf freundlich hinweisend, dass ich mit "mehreren" ca. sechshunderttausend meine,
RhombicosidodecahderonROFL! Ja das hat in der Tat ne negative Auswirkung, und zwar auf die werte Performance deines System
...
-
Wahrscheinlich hab ihr euch über meine Frage gewundert. Deswegen möchte ich erklären wich ich dadruf gekommen bin:
Soweit ich weiß werden Mutexe meistens nur verwendet, wenn man sichergehen möchte dass ein Programm nur einmal gestartet wird, z.B. ein Virus. Da Viren unterschiedliche Mutexe verwenden, wollte ich ein Programm schreiben, dass Mutexe, die genauso sind wie, die von den Viren - also für jeden Virus (laut AntiVir um die 590000) - , erstellt und somit die Ausführung der Viren verhindet, da das Virus denkt es sei schon aufgrund des Mutexes schon aktiv und schaltet sich (das Virus) wieder aus!
Scheinbar würde es dann wohl leicht zu Lasten auf das Betriebssystem gehen ...
Mit freundlichen Grüßen
Rhombiantivirusdodecahedron
-
Also.
1 Thread pro Mutex halte ich für ein (unwahres) Gerücht. Resourcen verbraten tuts trotzdem.Eine u.U. bessere Möglichkeit wäre es systemweit die KERNEL32.DLL zu patchen, und die "einfach so tun zu lassen" als ob all diese vielen Mutexe existieren würden.
Und BTW: Mutexes werden lange nicht nur verwendet um gegen "mehrfach laufen" zu schützen, sondern ne Mutex nimmt man wenn man mit einer CRITICAL_SECTION nichtmehr auskommt - z.B. weil man beim "locken" ein Timeout braucht, einen gemeinsamen Lock über Prozessgrenzen hinaus braucht oder vielleicht Zugriffsbeschränkungen auf das Synchronisierungsobjekt.
Und ich denke gerade die wirklich potenten und bösen Viren wirst du mit so einem einfachen Trick nicht lahmlegen können.
-
hustbaer schrieb:
Also.
1 Thread pro Mutex halte ich für ein (unwahres) Gerücht. Resourcen verbraten tuts trotzdem.Eine u.U. bessere Möglichkeit wäre es systemweit die KERNEL32.DLL zu patchen, und die "einfach so tun zu lassen" als ob all diese vielen Mutexe existieren würden.
Und BTW: Mutexes werden lange nicht nur verwendet um gegen "mehrfach laufen" zu schützen, sondern ne Mutex nimmt man wenn man mit einer CRITICAL_SECTION nichtmehr auskommt - z.B. weil man beim "locken" ein Timeout braucht, einen gemeinsamen Lock über Prozessgrenzen hinaus braucht oder vielleicht Zugriffsbeschränkungen auf das Synchronisierungsobjekt.
Und ich denke gerade die wirklich potenten und bösen Viren wirst du mit so einem einfachen Trick nicht lahmlegen können.
-
Trundle0x7e schrieb:
hustbaer schrieb:
Also.
1 Thread pro Mutex halte ich für ein (unwahres) Gerücht. Resourcen verbraten tuts trotzdem.Eine u.U. bessere Möglichkeit wäre es systemweit die KERNEL32.DLL zu patchen, und die "einfach so tun zu lassen" als ob all diese vielen Mutexe existieren würden.
Und BTW: Mutexes werden lange nicht nur verwendet um gegen "mehrfach laufen" zu schützen, sondern ne Mutex nimmt man wenn man mit einer CRITICAL_SECTION nichtmehr auskommt - z.B. weil man beim "locken" ein Timeout braucht, einen gemeinsamen Lock über Prozessgrenzen hinaus braucht oder vielleicht Zugriffsbeschränkungen auf das Synchronisierungsobjekt.
Und ich denke gerade die wirklich potenten und bösen Viren wirst du mit so einem einfachen Trick nicht lahmlegen können.
Ja und? In dem Artikel steht nirgends ein Wort davon dass pro Mutex ein Thread angelegt wird. Ist auch nicht so. Wenn du mir den entsprechenden Paragraphen zeigen kannst (zitiere den einfach hier), dann kann ich dir sagen was der wirklich bedeutet.
