multithreading vs interrupts
category: general [glöplog]
Hi,
we're in a controversy at csdb. what do you think, is the following technique implementing preemptive multithreading or just using interrupts? this is an often used method on the c64 to load while an effect is running:
1. the "main program" is running the loader code
2. when the vblank interrupt (call it that for ease of understanding) fires, it calls the effect, and sets a flag not to call it again until it is finished
3. thus if the effect doesnt finishes before the next vblank interrupt comes, it will be not called again. vblank interrupt exists silently. no stack overflow ;)
4. when the effect finishes, cpu is 'given' back to the loader until the next interrupt comes.
we're in a controversy at csdb. what do you think, is the following technique implementing preemptive multithreading or just using interrupts? this is an often used method on the c64 to load while an effect is running:
1. the "main program" is running the loader code
2. when the vblank interrupt (call it that for ease of understanding) fires, it calls the effect, and sets a flag not to call it again until it is finished
3. thus if the effect doesnt finishes before the next vblank interrupt comes, it will be not called again. vblank interrupt exists silently. no stack overflow ;)
4. when the effect finishes, cpu is 'given' back to the loader until the next interrupt comes.
Oswald, congrats, you've just invented DPC which is a standard technique for years on like every system that's not fully multitasking capable. Eg. almost every gaming console in existence ;)
(ok, on consoles you normally don't let the whole engine run in the interrupt but there are lots of routines that would normally exceed the size of the usual IRQ handler :)
(ok, on consoles you normally don't let the whole engine run in the interrupt but there are lots of routines that would normally exceed the size of the usual IRQ handler :)
kb, congrats, you're now talking like you're kb! Oh, wait, you are.
On the Z80, interrupts are automatically disabled when the interrupt routine starts, so you don't even need to maintain your own flag. (But you do need to remember to put an EI instruction at the end of the routine...)
gasman, c64 works the same, you have to manually enable irqs, if you want another one happen while inside one already.
and you would do that since c64 music players needs a call each frame. so, our theoretical vblank irq runs each frame and calls the music player each frame. but the call to the effect is only issued when it doesnt runs already. in this scenario the interrupt will interrupt itself: the code which is running the fx for more than one frame.
and you would do that since c64 music players needs a call each frame. so, our theoretical vblank irq runs each frame and calls the music player each frame. but the call to the effect is only issued when it doesnt runs already. in this scenario the interrupt will interrupt itself: the code which is running the fx for more than one frame.
i would call it "just using interrupts"
IMO, it's not really a decision anyway. "multithreading" is a pretty high-level concept that only really means there are two (or more) separate paths of execution active (in some way or other) at the same time, and that applies here. interrupts would be one of many ways to implement that concept, and also applies here. so i don't see why it can't be both :)
ryg, there has to be a difference between multitasking and multithreading .)
yes, buzzword compliance.
multitasking=running several independent processes. threads aren't necessarily independent; there typically is some amount of shared data, for example.
i would only call it multithreading when each thread has it's own stack, and when you are not limited to a small hardware dependent number of threads.
process, task, thread and fiber are just different names for the same concept. in windows, a process has the largest overhead and strongest separation while a fiber is supposed to be a low overhead / no separation mechanism. In other words: microsoft messed up their threads so badly that they needed something new.
process, task, thread and fiber are just different names for the same concept. in windows, a process has the largest overhead and strongest separation while a fiber is supposed to be a low overhead / no separation mechanism. In other words: microsoft messed up their threads so badly that they needed something new.
i would love to hear how interrupts are handled on a multicore machine...
Didn't read any of the thread but interrupts are just like calling a function but at random times.
I'm not sure if using interrupts for the demo and the loader should be called "multithreading". I think multithreading shouldn't be releated to vertical retrace.
skate, why not, there's not that much difference between the vretrace and the timer IRQ that's driving multithreading everywhere else. Depends on what you want to achieve.
I'm with chaos tho - real multithreading would require at least some context switching (stacks etc). Oswald still described Deferred Procedure Calls pretty well - which are a little more complicated version of layering IRQs on C64 ;)
I'm with chaos tho - real multithreading would require at least some context switching (stacks etc). Oswald still described Deferred Procedure Calls pretty well - which are a little more complicated version of layering IRQs on C64 ;)
please read my comment at CSDB. this topic does not truely reflect the discussion going on CSDB.