Linked by Hadrien Grasland on Thu 19th May 2011 21:31 UTC
Thread beginning with comment 474385
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
More Features »
Sponsored Links



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