Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - FlashBurn

Seiten: 1 ... 41 42 [43]
841
Lowlevel-Coding / Re: spinlocks
« am: 01. April 2010, 19:40 »
Zitat von: erik
Der BTS-Befehl ist ohne lock-Präfix aber nicht Multi-CPU-sicher! Warum das so ist habe ich in diesem Thread nun erschöpfend genug erklärt. In Deinem Quell-Code benutzt Du ja schließlich auch das lock-Präfix. Wenn man die Sicherheit will muss man auch den Preis für das lock-Präfix bezahlen!
Hier hast du mich ein wenig missverstanden. Was ich an dem Code den ich hier gesehen habe, zu beanstanden habe ist dass er ständig eine Schleife macht und ständig den Lock durchführt!

Deswegen sollte man ja auch die Test-And-Set Variante verwenden! Das man erst den Memorybus Locked wenn der Lock wahrscheinlich frei ist!

Zitat von: erik
(im Kernel ist ja nur aktives Warten möglich)
Wie kommst du darauf? Also mein Kernel beherrscht Semaphores (ihm ist es auch egal ob es ein User oder ein Kernel-Thread, da eh alles im Kernel läuft). Also das im Kernel nur aktives warten möglich ist, ist erstmal Quatsch, das ist ne reine Implementations Sache!
842
OS-Design / Re: Sysenter vs. Interrupts
« am: 31. March 2010, 22:55 »
Sysenter hat noch den Nachteil, dass das User ESP Register nicht gespeichert wird, das muss man selber machen (bevor sysenter ausgeführt wird) und da kann es zu Problemen kommen, weil man dann auch testen muss, ob die Page wo der Stack drin liegen soll auch wirklich ne User-Page ist und ob sie wirklich geladen ist. Ein weiterer Nachteil (auch von Syscall - AMDs Variante) ist das die Rückgabe eines 64bit Wertes nicht mehr Standardkonform gelöst werden kann, da das EDX Register bereits anders verwendet wird.

Ansonsten profitieren gerade Programme die oft die Syscalls aufrufen davon.
843
Lowlevel-Coding / Re: spinlocks
« am: 31. March 2010, 22:49 »
Wenn ich mich mal einmischen dürfte.

Geht es nur um spinlocks im User-Code oder auch im Kernel-Code?

Also erstmal wäre es nicht wirklich toll, wenn ihr eine Spinlock nur über xchg programiert (der lock Präfix ist wie gesagt sehr teuer, vorallem wenn man das ständig macht). Nicht umsonst gibt es die Test-And-Set Variante.

Ich bin leider noch nicht so weit das ich mir schon ne Rübe darüber machen müsste wie ich im User-Code nen Lock ohne in den Kernel zu gehen hinbekomme, aber ich würde nie eine Spinlock im User-Code nutzen. Ich meine stellt euch mal die Situation vor, der Thread bekommt die Lock und gleich danach wird der Scheduler aufgerufen und der Thread ist nicht mehr an der Reihe. Das würde heißen das er den Lock hat und alle anderen die Versuchen ihn zu bekommen müssen warten (und zwar mit einem busy-wait, ganz schlecht) und das kann unter Umständen schon mal ne Weile dauern. Das Problem ist hier halt, das man im User-Code die Interrupts nicht ausschalten kann. Problematisch ist es natürlich wenn man den Lock nur für ein paar Instruktion (Assembler-Anweisungen) braucht. Da wäre eine Semaphore/Mutex natürlich totaler Overhead!

Ich nutze folgenden Code im Kernel für meine Spinlocks:
struct spinlock_t {
uint32t volatile lock;
uint32t flags;
};

static inline void spinAcquire(struct spinlock_t *spinlock) {
asm volatile("pushfl\n\t"
"1:\tcli\n\t"
"testl $1,(%%eax)\n\t"
"je 2f\n\t"
"popfl\n\t"
"pushfl\n\t"
"pause\n\t"
"jmp 1b\n\t"
".align 4,0x90\n\t"
"2:\tlock bts $0,(%%eax)\n\t"
"jc 1b\n\t"
"popl %[output]\n\t"
"cli"
:[output] "=q"(spinlock->flags)
:"a"(spinlock)
:"memory", "flags");
}

static inline void spinRelease(struct spinlock_t *spinlock) {
//look if ints were enabled or disabled
asm volatile(""
:
:
:"memory");
spinlock->lock= 0;

if(likely(spinlock->flags & 0x200))
asm volatile("sti");
}

Ist halt die Test-And-Set Variante mit dem Deaktivieren der Interrupts.
844
OS-Design / Memory Management
« am: 15. July 2004, 20:46 »
Wieso ist eine Verwaltung mit Hilfe von Bitmaps shclecht, bzw. langsam? Man kann die Arbeit mit Bitmaps optimieren.

Ich nutze sie in meinem OS und es ist die einzigste Möglichkeit die mir eingefallen ist. Denn ich möchte nicht nur 4KiB Pages, sondern auch 4MiB Pages anfordern können! So dass die Stackvariante rausfällt. Zumal wenn man Multitasking einsetzt, wird man Paging nutzen und dort kann man immer nur 4KiB (im standard Modus) als kleinste Einheit verwenden, was die Bitmap auf 128KiB schrumpfen lässt. Diese 128KiB sind für mich vertretbarer als wenn ich einen Stack nutzen würde. Dann mal zu der DMA Geschichte. Darum würde ich mir keine Gedanken machen, denn ausser dem Floppydrive nutzt keiner mehr ISA-DMA, welcher nämlich auf 16MiB begrenzt ist. Wer eine Festplatte über IDE ansprechen will, kannn für DMA die vollen 4GiB nutzen!
Seiten: 1 ... 41 42 [43]

Einloggen