OSX begrenzt Multitasking fähig?!?

[MacMark]

Ich würde mal ohne die externen Geräte testen, nur mit Originalhardware.

 

[Randfee]

das kann auch ohne irgendwelche angeschlossenen Geräte passieren... Wie ich zuvor schon mehrfach gesagt hab, unwiderbringliches Einfrieren hab ich in diversen Apple Stores demonstriert und erntete nur noch Blicke wie "raus hier"... gg

 

[MacMark]

Dann starte mal mit gehaltener Shift-Taste. Er sollte dann etwas von safe-boot erzählen. Dabei werden nur die nötigsten und keine Dritthersteller-Kernel-Extensions geladen. Kannst Du ihn dann immer noch einfrieren mit VLC?

 

[Randfee]

mit VLC kann ich die Kiste ja nicht reproduzierbar einfrieren... ganz im Gegenteil. Ich denke nicht, dass das mit VLC irgendwas zu tun hat, der letzte build ist einfach wahnsinnig instabil, überall. Das sagen auch noch mehr als ich.

Das System friert meiner Meinung nach ein, über Finder Aktivitäten. Seit 10.4.6 läuft das WebDAV mit dem RWTH server auch, vorher fror der immer ein, schön nachvollziehbar, auf jedem OSX Rechner, den ich gefunden hab.

Jetzt ist das einfrieren sehr selten, aber es passiert, wie eben gestern abend

 

[MacMark]

Was muß ich tun, um meinen Mac einzufrieren? Ich will das mal nachstellen.

 

[Randfee]

OSX 10.4.1-5 und auf nen RWTH secure WebDAV account z.B. und da neue Folder erstellen. Ab 10.4.6 erhängt der Finder sich dabei nicht mehr, was ich natürlich super finde. Ab da weiß ich nix mehr um das zu reproduzieren, wenn mir wieder was über den Weg läuft schreie ich.
Was jetzt halt meist passiert sind Hänger und Einfrierer des Systems wie im thread beschrieben. Unlesbare CD im Laufwerk z.B. bewirkt evtl. kurze Hänger des Systems, der Menüleiset oder wie auch immer. Dabei kann es auch passieren, dass die Oberfläche ganz einfriert und auf nichts mehr reagiert, wie eben gestern wieder. Dies ist jedoch selten, kann aber passieren. In diesem Fall läuft keine Konsole mehr und oder, wenn diese noch läuft, bewirkt jegliches Kill Kommando eventuell garnichts.

 

[MacMark]

Was ist ein RWTH?

 

[Randfee]

sorry, RWTH ist meine Uni in Aachen. Den Webspace kann man nur über Secure WebDAV ansteuern. Das funktionierte unter Windows schon immer und seit 10.4.6 halt ordentlich.

 

[tjp]

Ich verstehe die technischen Zusammenhänge sehr wohl, ... wie ich dann auch weiter folgerte: es kann nicht sein, dass ein als Multitasking befähigtes System einfriert, wenn eine Applikation dicht macht.

Natürlich kann ein Multitasking OS sich so aufhängen, daß nichts mehr geht! Wenn die betreffenden Applikation nicht selbst abschmiert, sondern einen Kernel Call macht und dieser hängt, dann hängt je nach Design der ganze Rechner.

MacOS X ist in Relation zu anderen UNICES leider kein sehr gutes UNIX. Es werden viel zu viele Global Locks gemacht. Es gibt nun einmal Datenstrukturen im Kernel, die es erfordern, daß man sie sich reserviert bevor man auf sie zugreifen kann. Diese Zugriffe kann man mehr oder minder gut granulieren. Bei MacOS X ist das eher schlecht gelöst zum Beispiel bei Solaris sehr viel besser. Wenn nun ein Prozeß indirekt auf so eine Kernelresource zugreift und das System schmiert ab (der Kernel hängt zwar, aber es gibt kein Kernel Panic), dann steht der ganze Rechner, weil alle Kernelaufrufe, die einen Kernel Lock bräuchten leider bei MacOS X global (meines Wissens gibt es einen Lock für alle und nicht diverse wie bei anderen UNICES) blockiert werden. Das ergibt eine Deadlock Situation und nichts geht mehr.

 

[MacMark]

tjp, Du bist auf dem Stand von vor 10.4. Das ist heute jedenfalls nicht der Fall mit OS X.

Ergänzung: Neben einer erstmals eingeführten offiziellen Kernel-API bietet OS X seit 10.4 auch feinkörniges Kernel-Locking.

 

[civi]

Was ist ein RWTH?

Eine der drei Top-Technichen Hochschulen/Universitäten in Deutschland.

http://www.rwth-aachen.de/

 

[tjp]

tjp, Du bist auf dem Stand von vor 10.4. Das ist heute jedenfalls nicht der Fall mit OS X.

Wo gibt es den passenden Artikel oder Sourcecode, der Deine Aussage belegt. DAS würde ich gerne nachlesen.

 

[MacMark]

Wo gibt es den passenden Artikel oder Sourcecode, der Deine Aussage belegt. DAS würde ich gerne nachlesen.

Das findest Du nicht alleine? Mmh …

New in Tiger: Fine Grained Locking. Invite more threads to the party in your processor.

http://www.apple.com/macosx/features/unix/

Finer-grained locking is the obvious solution. Instead of restricting access to huge chunks of the kernel, locks can be placed in front of smaller pieces of functionality. For example, instead of allowing only one thread at a time to do "any network i/o" in the kernel, smaller locks can be placed on the various parts of the networking stack: memory buffers, sockets, the protocol layer, etc.

Since there can be as many threads running in the kernel as there are individual locked pieces, more locks means more threads and a lower chance that a thread will want exactly the same lock as another thread. The end result is less contention, and the ability to scale to a higher number of CPUs (or "cores" with multi-core CPUs, or "threads" with symmetric multithreading).

http://arstechnica.com/reviews/os/macosx-10.4.ars/4

BSD (specifically the file system and networking subsystems) used funnels until Mac OS X 10.4, whereupon they switched to fine grained locking

http://lists.apple.com/archives/darwin-kernel/2006/Oct/msg00091.html

In Tiger we introduce fine-grained locking (hey, it even made the marketing page <http://www.apple.com/macosx/features/unix/>), which makes funnels pretty much irrelevant. Some funnel stuff lives on (for example, if you're porting a VFS plug-in, you can request to be run under a funnel to simplify your porting efforts), but it's not relevant to the hot paths within the kernel.

http://lists.apple.com/archives/darwin-kernel/2005/Oct/msg00058.html

 

[lemming71]

ja, meinte präemptives Multitasking, was aber scheinbar nicht immer so läuft, wie es soll. Disconnected ein verbundenes Netzlaufwerk, so kann sich das System erhängen, hat man kein terminal auf, bekommt man den Finder nichtmal gekillt, manchmal geht auch das nicht.

Ich weiß zu wenig über die Struktur von OSX, aber manchmal hab ich das Gefühl der Finder ist so verworren darin wie der Internet Explorer und Mediaplayer in Windows.
Das Netzwerkproblem und das CD-kopier-Problem mit dem Aufrufen der "Datum & Uhrzeit" Systemsteuerungen über die Menüleiste (auf die Uhrzeit klicken) sind reproduzierbar, grade auf nem Powerbook ausprobiert... hm...
Aber selbst das ist nicht so wichtig. Wären die tasks in OSX wirklich unabhängig, dann würde das System ansprechbar bleiben!!!!

Nunja, präemptives Multitasking halt. Wenn eine Anwendung meint sie braucht viel Rechenpopwer und dementsprechend eine große Scheibe vom Kuchen, dann müsse die restlichen Krümmel halt warten. Versuche es mal mit Renice oder so. UIst ein Terminalbefehl, der einzelnen Anwendungen mehr bzw. weniger Priorität zuweisne kann. Ich glaube die zuläössigen Wert gehen von -20 bis 20, wobei 20 die niedrigste Priorität hat

 

[Randfee]

@lemming71
ja, das kenn ich. Was ich aber nicht weiß, gibt es einen Befehl werlcher der Oberfläche Rechnezeit reserviert, welcher dann in keinster Weise angetastet werden kann?

 

[tjp]

Das findest Du nicht alleine? Mmh …
http://www.apple.com/macosx/features/unix/

Apple Marketing Geschwätz wie üblich, leider wenig informativ.

http://arstechnica.com/reviews/os/macosx-10.4.ars/4

Danke, der Link ist hilfreich.
Allerdings als Nutzer von 10.4 muß ich sagen, daß es noch ein sehr weiter Weg ist, bis Apples MacOS X sich mit Solaris messen kann. Die vielen Hänger der Benutzeroberfläche in denen man den Ball sieht kenne ich von Solaris nur dann, wenn die Maschine out of Swap geht, bei den neueren Installationen passiert das nur wenn /tmp auch voll war. Das Ereignis war entsprechend selten. Bei MacOS X darf man öfters warten. Der Finder ist oftmals die Ursache.

 

[tjp]

Nunja, präemptives Multitasking halt.

Nö, das Problem liegt im Scheduler bzw. generell im Kernel. Solaris ist sehr viel besser unter Last zu bedienen. Linux war unter den alten Kernel Versionen unter Last faktisch nicht mehr zu benutzen. 2.6 funktioniert halbwegs unter Last.

 

[MacMark]

typo fix

Nunja, präemptives Multitasking halt. Wenn eine Anwendung meint sie braucht viel Rechenpopwer und dementsprechend eine große Scheibe vom Kuchen, dann müsse die restlichen Krümmel halt warten.

Das ist kooperatives Multitasking von Mac OS 9 und früher. Bei präemptiven Multitasking teilt das Betriebssystem die Zeit zu. OS X ist sogar echtzeitfähig.

Versuche es mal mit Renice oder so. UIst ein Terminalbefehl, der einzelnen Anwendungen mehr bzw. weniger Priorität zuweisne kann. Ich glaube die zuläössigen Wert gehen von -20 bis 20, wobei 20 die niedrigste Priorität hat

Für Werte unter 0 kann der normale User nicht einstellen

 

[MacMark]

Apple Marketing Geschwätz wie üblich, leider wenig informativ.

Wie despektierlich! Man muß wichtige Kernel-Neuerungen auch Nicht-Technikern in wenigen Worten erklären können. Das ist keineswegs Geschwätz.

Danke, der Link ist hilfreich.
Allerdings als Nutzer von 10.4 muß ich sagen, daß es noch ein sehr weiter Weg ist, bis Apples MacOS X sich mit Solaris messen kann. Die vielen Hänger der Benutzeroberfläche in denen man den Ball sieht kenne ich von Solaris nur dann, wenn die Maschine out of Swap geht, bei den neueren Installationen passiert das nur wenn /tmp auch voll war. Das Ereignis war entsprechend selten. Bei MacOS X darf man öfters warten. Der Finder ist oftmals die Ursache.

Der Finder kann soviel hängen wie er will. Er ist ein User-Space-Programm und sein eventuelles Hängen hat nicht zwangsläufig mit dem Kernel zu tun. Eher beispielsweise damit, ob der Finder einen getrennten Thread für das Mounten von Volumes nutzt oder nicht.

 

[Cyrics]

Nö, das Problem liegt im Scheduler bzw. generell im Kernel. Solaris ist sehr viel besser unter Last zu bedienen. Linux war unter den alten Kernel Versionen unter Last faktisch nicht mehr zu benutzen. 2.6 funktioniert halbwegs unter Last.

Ich wollte auch erst behaupten, dass das Problem doch am Scheduler liegen muss. Aber bei näherer Betrachtung scheint es doch eher so zu sein, dass der Prozess sich aufgehangen hat, klassisch: keine Rückmeldung. Der Scheduler hat auf jeden Fall ein Zeitlimit (Timeslice) vorgegeben und den nächsten Prozess am Start. Allgemein ist es doch so, dass egal welcher Scheduler-Algorithmus verwendet wird, sollte ein solches Szenario nicht möglich sein.
Der Dispatcher scheint eher in meinen Augen zu versagen! Wieso wird es nicht geschafft den Prozess den Gnadenstoß zu geben? Wieso bleibt der Prozess auf dem CPU und belegt weiterhin Ressourcen?

Eine Konstellation zu erstellen, dieses Szenario nachzustellen, schaffen anscheinend nur sehr wenige.
Mir ist ein richtiges Einfrieren des GUI bisher nur einmal in 2 1/2 Jahren OS X auf meinem iBook passiert. Sonst gab es schon 4 Kernelpanics aufgrund von externen Laufwerken.

@Randfee
Renice etc. ändern nichts am Hauptproblem... das mag vielleicht den Scheduler beeinflußen, aber der Prozess wird dadurch trotzdem nicht vom CPU geholt. Wenn er vielleicht reagieren würde und der Dispatcher ordnungsgemäß seine Arbeit verrichten würde, dann würde der Renice vielleicht greifen.
Die graf. Oberfläche ist sonst übrigens kein einzelner Prozess dem man gesonderte Priviliegen beim Prozessmanagment übergeben kann.
Jedes Programm liefert je nach Art der Programmierung eine grafische Oberfläche mit oder nicht. Diese arbeitet oft getrennt als eigenständiger Prozess oder Thread. Je nachdem... und damit kommen wir zum eigentlichen Problem wo ich hinwollte: der Finder hat 100%ig mehrere Threads am Laufen. Selbst beim Multiprozessor-System kann ein Prozess bzw. dessen Threads jeden CPU gleichzeitig belegen. Jedoch kommt es hier auf die Berechtigungen an. Der Finder z.B. läuft als Benutzerprozess und hätte damit nicht die nötigen Rechte für. Damit kommen wir zu den Problemen des Benutzerprozesses... wird z.B. ein Thread von den 5 oder mehr ausgelastet bzw. beansprucht die Rechenzeit für sich allein, gucken die anderen dumm aus der Wäsche. Denn die Threads laufen nicht parallel ab sondern dürfen warten. Im Worst-Case wird vielleicht der Prozess kurz im Cache geparkt, durch den Dispatcher, aber gleich danach aufgrund seiner Dringlichkeit wieder auf den CPU geholt, und dann rechnet genau dieser rechenhungrige Thread wieder die ganze Zeit weiter. Die anderen Threads haben keine Chance, bis der Thread endlich mal aufhört so egoistisch zu sein.
Vielleicht ist das ja das ganze Problem. Aber wer weiß... bei Apple ist sicher mal wieder alles sehr speziell und anders

ich wollte nicht verwirren sondern die eigentliche Problematik mal wieder in den Vordergrund rücken, wo es in meinen Augen scheitert. Da sich ja kein Muster bisher erkennen lässt, würde ich das ganze einfach mal dokumentieren bis ein Muster auftaucht.