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.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2011-01-28
"Actually, you have this problem even if you have several distinct async drivers running side by side. As soon as there are shared resources, there is a synchronization overhead."
I wasn't careful with my wording, we can run many instances of the async model within multiple threads and/or processes, which can communicate to each other using lock free message queues. So although they can share certain resources this way, it's not a shared resource in the traditional "I hold the mutex" sense.
"Joking aside, I think that anything that requires some reactivity (and most drivers are included) should never, ever, depend on blocking file I/O."
I agree with you, but you do realize that this is how nearly all IO is handled in linux?
"Are all drivers fundamentally serial in nature and doing little processing ?"
I was responding to your comment about using MT graphics rendering, which I agree could benefit. However many devices are inherently serial.
"Some time ago, I was wondering about an efficient way to do an FTIR touchscreen driver."
Hey I built one myself! Drilled LED holes into a picture frame, except I used visible light.
"Blob detection and tracking might work first by locating blobs in the initial pictures the brute-force way"
That's a delightful project, I built something very similar in college, but they took down the project page. This is exactly the kind of thing I wanted to do with my degree!
"Interesting problem, actually. I think once one thread starts to hog the memory bus like this, we're doomed anyway".
Yes, but the point of my example was that IO bound processes don't benefit by running in parallel since they can displace CPU bound processes which do run in parallel. We already seem to agree on this point.
Edited 2011-05-24 20:18 UTC
Why does Google get so much credit in the technology industry? Why, despite the company's many obvious failings, do many geeks and enthusiasts still hold a somewhat positive view on the all-knowing technology giant? A specific talk at Google I/O this week provides the answer.
OSNews is a sponsor of this year's O'Reilly OSCON in Portland, Oregon, USA. A lucky OSNews reader will win a free three-day pass, including two tutorials days. To win the pass, post a comment on this story saying something about Open Source Software or OSCON. We'll pick a winner at random next week. If you don't have an OSNews account, you may email us your entry. Part of the conference is the 9th annual Open Source Awards, and today the 16th is the deadline for nominations. If you'd like to nominate an outstanding open source contributor, do it here. Read on for more information about OSCON. Update: The 20% discount code for OSNews readers is "OSN."
"Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
This is one of those news items that's fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It's all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products - which have Haiku and TuneTracker pre-installed.
Exactly twenty years ago, a document was published that played a huge role in establishing the web as we know it today. Twenty years later, and this simple and straightforward document is proof of an irrefutable fact: while closed technologies can change markets, open technologies can change the world.
Oh multitasking. That staple of computing that got thrown out the window with many modern smartphones. We got some rudimentary thing in its place - but even as multitasking on phone and tablets improves, its user-visible side remains cumbersome. Windows 8 has a neat implementation, and now it's time Android follows in it footsteps.They're here! Whether that excites you or not remains to be seen, but the Galaxy S4, which will most likely become the best selling Android smartphone of the year by a huge margin, has been reviewed by all the major sites, and there's lots of interesting conclusions in there - although I think most of you will get the gist.Nokia has posted its quarterly results for the first quarter of 2013, and just like the quarters that came before, there's not a whole lot of good news in there. The rise in Lumia sales still can't even dream of making up for the sales drop in Symbian phones, and when broken down in versions, the sales figures for Windows Phone 8 Lumias in particular are very disappointing. In North America, Nokia is getting slaughtered.The day has finally come: Google has started shipping Google Glass to the lucky few early adopters. Now that it's shipping, Google has also unveiled a lot more about the API and the specifications of the device itself. While the company had already given out substantial details at earlier occasions, there are still a few surprises here.
Almost exactly three years ago, I wrote about why OSNews was no longer OSNews: the alternative operating system scene had died, and OSNews, too, had to go with the times and move towards reporting on a new wave of operating systems - mobile, and all the repercussions that the explosion of smartphones and tablets have caused. Still, I was wondering something today: why aren't we seeing alternative operating systems on mobile?
Member since:
2010-03-08
Sorry for the delay, I have been too sick for complex thinking during the last few days.
Actually, you have this problem even if you have several distinct async drivers running side by side. As soon as there are shared resources, there is a synchronization overhead.
But I'm a bit curious about why separate drivers would need to share much resources with each other. It seems that you provide an example below, though so I'm reading a bit further.
Two userpace apps read from two different files. In the threaded model, this results in two user+kernel threads blocking in the file system driver, which itself has blocked in the block device driver.
Aggggghhhhhh... Disk I/O in drivers ! u_u Banish these impure thoughts from your head before becoming a fiendish servant of Satan ! You can still see the light !
Joking aside, I think that anything that requires some reactivity (and most drivers are included) should never, ever, depend on blocking file I/O. Nonblocking file I/O (like writing things is a log without caring when it's actually written to disk) is totally okay, on the other hand, but in this case we wouldn't have so much synchronization problems.
I've already admitted before that for something as I/O centric as a disk/block device driver, where there is only little processing involved, queuing events in an async model is probably best
You see, this is actually something I'm wondering about. Are all drivers fundamentally serial in nature and doing little processing ?
Some time ago, I was wondering about an efficient way to do an FTIR touchscreen driver. In case you've not heard about those, their sensitive layer uses infrared light trapped within a piece of glass through total internal reflexion, that can only be scattered outside of the glass when something (like, say, a finger) comes in contact with the it. A webcam captures the infrared image, everything from that point must be done in software.
So we have to do a webcam driver, a blob detection/tracking system, and some kind of real time video output.
Now, I don't know what kind of data comes out of a webcam, but I guess it varies from one webcam to another. Maybe some will output raw bitmap pictures, some will output jpeg frames, and some will output MPEG-ish videos with i-frames and p-frames. Most peripherals send an interrupt when their output buffer is full, so we do not know how many frames will have to be processed at once (especially for variable-sized frames like in MPEG video).
Suppose that our blob detection/tracking algorithm works with bitmap data. Then there is some amount of image conversion involved. In case the frames are sufficiently independent from each other (not guaranteed for MPEG, but certainly the case for JPEG), it's better to do the decoding in parallel because it's essentially a cpu-intensive operating, and nothing scales better on multiple cores than independent operations.
Blob detection and tracking might work first by locating blobs in the initial pictures the brute-force way (tresholding + noise removal + locating sufficiently large packs of pixels in the whole picture) and then by only looking for the blobs in a region around their former positions, based on their estimated speed. Since no writes are involved, no synchronization is needed, and looking for blobs in these slices of pictures can be done on a "one-thread-per-slice" basis, with communication between threads only needed when such slices overlap each other and it's difficult to know to which slice a blob belongs.
Edited 2011-05-24 09:53 UTC