Fast scheduler ...

[Pype.Clicker]

uh? not sure to get what you meant, but that "operating mode" is one of Clicker's main targets since 1999, or something alike ???

[Therx]

Surley an events queue won't stop the MP3 player jumping, because it is taking no input. You'd have to add a system function which allowed a process to get itself added to the events queue every X secs

[Tim]

An MP3 player is constantly getting input -- from the sound card. The sound card should give an interrupt when it has finished playing the current buffer, at which point you can fill another buffer and send it to the card. For click-free playback, fill the next buffer while the sound card is playing the current one; when the card interrupts, swap buffers.

[beyond infinity lazy]

that's interesting. so, the sound card driver has an interrupt handler which gets triggered as soon as sound card has finished current work.

what troubles me: Should the interrupt handler do the buffer swapping/filling - to have the soundcard play back smoothly and then notify the driver of this event? or shall it just notify the driver so it takes care of the sound card buffer?

[Solar]

Not sure to get what you meant, but that "operating mode" is one of Clicker's main targets since 1999, or something alike ???

Then it's a case of parallel thinking. When I started with Pro-POS, I didn't know (much about) Clicker, but "scheduling modes" were one of the first Pro-POS concepts that made it into writing.

The idea came up while reading the book "Systemsoftware" by Nehmer / Sturm, more precisely when reading a paragraph on how most of the goals for a scheduler are orthogonally opposed to each other, and that a scheduler delivering high throughput (server) cannot deliver high responsiveness (desktop) at the same time. I just thought "D'oh, so a server needs a different scheduler module than the desktop", and the idea stuck.

[Pype.Clicker]

what troubles me: Should the interrupt handler do the buffer swapping/filling - to have the soundcard play back smoothly and then notify the driver of this event? or shall it just notify the driver so it takes care of the sound card buffer?

The good' ol' SoundBlaster Pro had a programming mode where you could tell the DMA to deliver 64Kb chunks and the soundcard to interrupt every 32Kb chunks, thus implementing double buffering (buffer is played by the soundcard while buffer[(i+1)%2] is being rendered by software).

As the ISA DMA had the ability of re-starting the same transfer as soon as the transfer was completed, you could have the card playback uninterrupted provided that you manage to fill half the buffer between 2 notifications (IRQs) from the sound card ...

What becomes more complex to handle once the system gets multithreaded is that your IRQ just wakes up a thread and (usually) put it at the end of the scheduling queue. In case of a heavy-loaded system, it may occur that too many threads are before you so that you can't be served on time.

By the mean of prioritized events mechanism (and possibly a control admission that will tell you 'nah. I already have too much threads in "multimedia" class. Create your thread in another class or terminate some multimedia application first'), i hope being able to shorten the notification delivery ...

[Tim]

What becomes more complex to handle once the system gets multithreaded is that your IRQ just wakes up a thread and (usually) put it at the end of the scheduling queue. In case of a heavy-loaded system, it may occur that too many threads are before you so that you can't be served on time.

This is why Windows gives priority boosts to threads just after they finish some kind of I/O, with the size of the boost determined by the device they are talking to. This boost is intented to give a thread more of a chance of processing data it has just received, or sending more data, before the boost is removed at the end of the current quantum.

This would usually solve the MP3 player problem, because once the sound card had finished, the player thread would be boosted one or two levels above normal, giving it time to decode the next chunk and queue it at the sound card. As long as it can do the decoding in less than the time between interrupts, you get uninterrupted playback.

[Pype.Clicker]

@tim: interresting technique. Where did you learn all those stuff about NT (oh, i guess you're talkin' about NT as all Win9x i tried failed to achive this as soon as some other device (including disk, floppies, win modem, printers, scanners, etc.) are running ...) ?

Did it continue giving good performances when the disk where the MP3 is from is heavily requested ? (okay, this is more a I/O scheduling problem here, but i just wished to know :p ) and when software post-mixing is applied ?

I think i should really get a book on NT programming ... <voice="Budo-Sensei">Knowing Yourself without knowing your Enemy only gives you *half a chance* to win</voice>

[Solar]

Where did you learn all those stuff about NT?

Those are the moments I always feel the itch of suggesting my two most favourite books on OS design, only to realize (again) they are only available in German...

However, I am sure "even" the English speaking world has some books on OS design that use Unix and Windows NT for examples. It is sure worth checking your local book store for them; there is lots of wisdom to be found in such comparisons, about the do's and don'ts.

[beyond infinity lazy]

hmmmm... i'd be glad to learn about them. No problem with german ]:->.

The text I refer to mostly is Andrew Tanenbaum: OS Des & Implementation II.

[tom1000000]

...only 1 thread needs to be at 7 assuming there's 1 gui.

Erm... certainly you'd want your GUI to be multi-threaded, no?

...threads that want level 6 must not use too much cpu...

One idea from the dynamic feedback scheduling concept is penalizing high-priority threads for using up their timeslice by reducing their priority.

...and if the cpu load is getting heavy then if more threads want to upgrade to level 6 they will be denied.

Be careful: Most threads are started by software. "Denying" a thread basically means breaking the application.

You'd also be inviting the disadvantages of a "hard" real-time system (as load increases, tasks might be denied) with the disadvantages of a non-real-time system (no guarantees).

Also if a thread is at say level 5, but is hogging the cpu, the schedular will dump it down a level or 2. Trying to give priority to the less demanding threads.

That's feedback scheduling in a nutshell.

However, be aware that for some systems - those aimed at computational throughput, like i.e. a rendering station - this is not optimal. They might actually want the CPU hog (rendering engine) to run at high priority.

Basically depends of the type of system you are designing the scheduler for.

Yes my ideas are very rough. What I meant by "denying" the thread was that threads start with a default priority eg 2. I would "deny" their request to be upgraded to 6 or whatever. They would still run!

Same with limiting threads at other levels. They would still run, just at lower priority.

As a GUI would be multithreaded that was a silly comment by me. Have to restrict level 7 to the GUI process.

As for processes that are supposed to hog the CPU, I would say they threads with priority 4 or below never get downgraded for using their entire time slices. Only those that want 5 or 6.

So that would make it feasible?

[Solar]

hmmmm... i'd be glad to learn about them. No problem with german ]:->.

Nehmer / Sturm, "Systemsoftware - Grundlagen moderner Betriebssysteme", d-punkt Verlag. My personal favourite. Highly recommendable to get the basic concepts of a great many things, with just the right amount of depth to make you hunger for more.

R?diger Brause, "Betriebssyteme - Grundlagen und Konzepte", Springer-Verlag. (Currently not available; 3rd edition to be released September 2003.) More depth, more information, a little less "entertaining" than the Nehmer / Sturm book.

Both books together have less pages than the Tanenbaum, and having read both of them and the first few chapters of Tanenbaum, I claim either of the German books offers more value for the money. Tanenbaum always makes me fall asleep (which is why I haven't read more yet).