ist VB zu bremsen ?



  • Original erstellt von Lars:
    Dir ist klar das die Absenderadresse beliebig einstellbar ist 😮

    Ein Restrisiko. Außerdem unterstellst Du damit, daß ich sofort ohne Rückfrage lösche...



  • Original erstellt von Marc++us:
    Ein Restrisiko. Außerdem unterstellst Du damit, daß ich sofort ohne Rückfrage lösche...

    Hab ich nicht unterstellt. Ich hab nur gesagt das die Absenderadresse fälschbar ist, sogar ohne Probleme, für jeden der google bedienen kann.



  • Deswegen mache ich ja eine Rückfrage...



  • Deswegen mache ich ja eine Rückfrage...

    Hacker koennten den Datenverkehr manipulieren und deine Rückfrage an jemand

    anders schicken.



  • die programmierer sind nicht dafür verantwortlich, dass andere als ihre programme weiterhin schnell ablaufen. das sollte das betriebssystem nache: preemptives multitasking heißt das zeug.



  • Hey - "Schnell" und "Langsam" sind doch die völlig falschen Begriffe!
    Die CPU arbeitet alles im gleichen Takt ab. Sie "bremst" doch die Taktfrequenz nicht runter!
    Aber mit ungünstigem Schleifen-Design kann jeder trotzdem die Abarbeitung anderer (eigener) Programmteile oder anderer Programme "ausbremsen". Jedenfalls in Windows. Und für VB gibts ja extra DoEvents() deswegen. Und in C/C++ unter Windows nimmt man dafür Threads. Die "Arbeit" wird aufgeteilt, weil das OS jedem Thread seine Zeit zuteilt. Ist einer voll beschäftigt, so arbeiten die anderen (quasi parallel) trotzdem weiter. Nur wer ALLE Arbeit in EINEN Prozess packt, braucht sich nicht zu wundern, dass die restlichen Programmteile nicht zum Zuge kommen, weil irgendwo weiter vorn eine Schleife alle CPU-Zeit "verbrät".

    Alles klar?

    Blackbird



  • @Kevin@Uni
    Eher unwahrscheinlich.

    @irgendwer
    Sehe ich auch so.



  • Original erstellt von <irgendwer>:
    die programmierer sind nicht dafür verantwortlich, dass andere als ihre programme weiterhin schnell ablaufen. das sollte das betriebssystem nache: preemptives multitasking heißt das zeug.

    Doch, das ist Aufgabe des Programmierers.

    Und erste Devise auf Multitasking-Systemen ist: programmiere multitaskingfreundlich.

    Das hier ist nicht die Windows 3.11 Debatte! Preemptives Multitasking gibt's auf allen 32-Bit-Systemen zur Zeit, es ist immer das gleiche Problem:

    Wenn Du in einem Task z.B. ein while(!zustand()); reinschreibst, was passiert? Wie reagiert der Scheduler darauf?

    Du hast ihm gesagt: warte so oft wie möglich. Also wird der Scheduler bei einem nicht zu 100% belastetetem System der while-Schleife alle freie Rechenzeit zuordnen, weil der Task ja (anscheinend) die volle CPU-Leistung braucht.

    Sowas ist daher unfreundliche Multitasking-Programmierung.

    Wie wirkt sich das auf das Systemverhalten aus? Nun, wenn das System unter Vollast steht, wird es bei der Taskumschaltung insgesamt träger. Auch wenn ich ein neues Programm starte dauert der Startup länger, weil der Scheduler erst CPU-Zeit für den neuen Task freimachen muß. Der Rechner funzt natürlich immer noch, seine CPU-Zeit wird aber ineffektiv genutzt. Denn Warten sollte der Scheduler (der weiß wie das geht), nicht eine Schleife.

    Das Problem ist uralt auf Multitaskingsystemen, sowas mußte man schon bei OS/9 beachten.

    Lösung dafür ist zum einen, daß Tasks auf Events warten, d.h. der Task macht so eine Art wait_for_signal(something) und gibt seine Rechenzeit ab. Damit braucht er 0% CPU-Last.

    Dies ist nicht immer realisierbar - manchmal muß man ja in der Schleife was tun, eine Iteration durchführen z.B. Auch da ist es aber nicht nett, wenn man nun Zyklus für Zyklus durchklopft. Man sollte von Zeit zu Zeit seine Zeit kurz abgeben, um zusätzliche Belüftung ins System zu bringen - z.B. unter Windows mit einem sleep.


Anmelden zum Antworten