OSnews Asks on Interrupts: More Results
Linked by Hadrien Grasland on Thu 19th May 2011 21:31 UTC
Hardware, Embedded Systems Having read the feedback resulting from my previous post on interrupts (itself resulting from an earlier OSnews Asks item on the subject), I've had a look at the way interrupts work on PowerPC v2.02, SPARC v9, Alpha and IA-64 (Itanium), and contribute this back to anyone who's interested (or willing to report any blatant flaw found in my posts). I've also tried to rework a bit my interrupt handling model to make it significantly clearer and have it look more like a design doc and less like a code draft.
E-mail Print r 2   36 Comment(s) http://osne.ws/j3v
Permalink for comment 474044
To read all comments associated with this story, please click here.
RE: Pop-up threads
by Neolander on Fri 20th May 2011 22:29 UTC in reply to "Pop-up threads"
Neolander
Member since:
2010-03-08

I am concerned that you are still claiming that running threads is more scalable than a non-threaded approach. It is false. More flexible, yes, more scalable (or better performing), no.

If things which can run in parallel run in parallel, you get better scalability than with an all-sequential model like async. That's why we have threads at all. They are cheap (or more exactly can be made so). Why not use them ?

As per usual, I'll note that threads are best suited for CPU bound tasks with relatively rare synchronization. Popup/Micro-threads doing trivial tasks are typically short-lived with high overhead.

If the task is not CPU-bound, and we consider IO waiting times that are typically orders of magnitude larger than instruction execution times, the overhead of creating a thread, which is pretty small on modern hardware, will be irrelevant, since creating a thread is essentially a CPU/memory-bound operation.

If the task is CPU-bound, threads offer significantly better performance.

So you either lose nothing or win a lot. I don't know what's the problem with that.

Thread creation and accounting cost can be reduced to the bare minimum, but synchronization primitives will always be an inherent bottleneck since they cannot operate at CPU speeds and must be serialized over the bus. As the number of micro-threads increases, the bus itself becomes a point of contention and thus the entire system looses performance.

Again, I'll refer to the asynchronous model as having solved these problems. By handling events asynchronously without threads, all of the overhead disappears since no blocking/synchronization is necessary. Since only one stack is needed for CPU, it should fit entirely within the CPU's L1 cache.

If so much synchronization is needed that it has a significant impact on interrupt processing speed, it is indeed better to use async. That's another reason (apart from the big developer laziness one) why I support both models.

This doesn't even get into the prevalence of multi-threaded bugs and the difficulty in debugging them.

That's why I talk about ease of programming. Multi-threaded programming is harder. You have to get in the right mindset to get it right. But once you get some basic coding patterns that prevent deadlocks and races, I don't think there are so many things that can go wrong.

If a long running thread is really needed, then the asynchronous code can spawn one off deliberately (and still without blocking).

Which implies going back to the kernel, creating a thread, and waiting until the scheduler dares to run it. Why not have the kernel just do it right away ?

If you are using threads to achieve some type of kernel protection between stacks, then I wish you'd just say that. Please don't claim that micro threads are used for scalability when other alternatives are technically more scalable.

Again, how can processing events sequentially be any more scalable than processing them in parallel ?

But yeah, you're right, separate threads have also other benefits, like a stack/CPU state cleanup each time a new event is processed, or way to introduce "timeout" mechanisms so that if an event takes too much time to be processed, the driver simply reverts the changes and jumps to the next event (effectively reducing the impact of hung drivers).

Anyways, since you don't mention it, how do you handle the acknowledgement of interrupts? Is this done implicitly by the global interrupt handler? Or is this done within the thread that handles the interrupt?

Yeah, I implicitely included it in "enabling interrupts again". Drivers shouldn't be trusted for that, in my opinion.

The reason I ask is if you ack the int right away, then the hardware could fire off another interrupt and have you create a new thread for the same device before the first thread is serviced.

Yup, that's the whole point of using a threaded model at all. If you don't want this behaviour, you use the async model and run the pop-up threads sequentially.

Do you protect from this somehow or do you leave it up to individual drivers?

Drivers have to explicitely make a choice between using a threaded or an async model. If they use a threaded model for an interrupt where races can occur, they know what they're doing and it's up to them to implement the relevant synchronization mechanisms.

Edited 2011-05-20 22:35 UTC

Reply Parent Score: 1