I’m going to become short of suitable title suffixes pretty shortly… Anyhow, I have also reviewed interrupts on the MOS 6502 for the sake of extreme completeness, bust most importantly have tried to address some very incomplete and misleading statements of the interrupt handling model about pop-up threads and service-providing processes in a rather extensive way, see this post.
@Alfman :
So you mean that they only manipulate “abstract” system resources which are mutex’d layers below in a way they don’t have to care about ?
I still don’t understand how having threaded and async drivers running side by side prevents this.
Aw, cr-p, I had forgotten that on UNIX, everything is a file
What I meant is that drivers shouldn’t rely on blocking file I/O based on extremely slow mass storage devices (at the CPU scale). They’ll probably need blocking I/O with the device which they “drive” at some point, on the other hand, though callbacks may also be used for that purpose for longer transfers…
If serialization is only needed in the end, it’s not so much of a big issue as long has some amount of processing occurs before : we can do the processing first, and send results later. Question is : is serialization also needed at many other points (ex : drivers who need to frequently alter the state of the device), or is there little amount of processing involved ? In both cases, async would be better.
Didn’t you have issues with the ambient light of the room ? IIRC, advantages of using IR are that 1/IR leds are cheap and 2/Light scattered by the finger can’t affect the projected image, and 3/There’s less parasitic light in the near IR range than in the visible range.
“So you mean that they only manipulate ‘abstract’ system resources which are mutex’d layers below in a way they don’t have to care about ?”
No, not really what I mean.
Look at some atomic opcodes:
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
These atomic functions are the basis of many lock-free algorithms. This one is particularly useful to create lock free structures:
__sync_bool_compare_and_swap
It’s typically used in a loop to see if another thread got there first, and if so, try again.
We can use it to adjust the head of a queue in one single atomic operation. No mutex is needed because the operation is atomic. No other thread can mangle it even if running from another CPU.
“I still don’t understand how having threaded and async drivers running side by side prevents this.”
A mutex is used to create a critical section, such that two threads can coordinate manipulation of shared objects.
However, if a lock free message queue could be used to send instructions to a remote thread in charge of manipulating the “shared object” (which is a misnomer at this point), then there’s no need for a mutex/critical section.
Both threads can operate in parallel without a mutex by communicating through message queues.
An actual implementation might have to place limits on the queues to tell the sender to stop and start again. Arguably this could develop emergent characteristics resembling a semaphore.
“Question is : is serialization also needed at many other points (ex : drivers who need to frequently alter the state of the device),”
I think it’s very likely most drivers will acquire a mutex at the top of their functions, and release it at the bottom. And there’s nothing wrong with that (in fact it’s even necessary). However I’m guessing that in layered drivers this will have a redundant serializing effect with no parallelism at all.
“Didn’t you have issues with the ambient light of the room?”
If the far side of the glass is tinted, the light shining through isn’t bad. With visible light, your fingertips glow (on the opposite side). However I never projected anything onto the glass, as much as I wanted to, I couldn’t afford the projector.
“IIRC, advantages of using IR are that 1/IR leds are cheap”
Colored leds are pretty cheap too.
“and 2/Light scattered by the finger can’t affect the projected image”
I couldn’t really see the light out of the pane inside my frame. If any light exited the front of the pane as it was touched, I didn’t see it through my finger.
“and 3/There’s less parasitic light in the near IR range than in the visible range.”
Very possible.
My semaphore implementation allows one to do something like this, actually
I added it with the hope that people would think more before blocking.
Anyway, now I understand what you’re talking about, but not what’s the problem with mixing async and threads yet. So I move on…
Yes, I agree that in some times blocking can be avoided when synchronizing operation of two threads. T2 may have something else to do while T1 is in the critical region.
Depends. For two-way communication, you can simply use two half-duplex message queues so that threads don’t have to synchronize while writing in each of their side of the “pipe”.
In such a case, a synchronous approach is best, since you can only process one task at a time due to mutual exclusion.
You should have borrowed one to the university
I think that you could have two problems when adding it though :
-Reflexion of visible projected light in the camera.
-Far side tinting reduces projected image’s brightness too much.
Fair point ^^
Okay. I would have thought that since scattering is omnidirectional and should also slightly happen on the sides of the finger, a bit of light could have escaped in the form of a thin halo around the finger. If not, everything is fine.
See this for the difference in brightness in an usual setup : http://www.youtube.com/watch?v=ZexO_jtjx3M
Edited 2011-05-25 09:44 UTC
Neolander,
“Anyway, now I understand what you’re talking about, but not what’s the problem with mixing async and threads yet. So I move on… ”
I’m having trouble parsing your sentence. Are you asking if IO async can be mixed with IO threads?
Yes, but it’d need to be somewhat indirect since the async model isn’t supposed to block on semaphores/mutex.
The async process could call a variant of the mutex which polls rather than blocks, but that’s not really acceptable. Ideally we’d have a variant of the mutex (compatible with the mutex used by threads) which signals when it’s ready instead of blocking and waiting.
A userspace app could emulate these signals by employing a thread wrapper to grab a blocking mutex, then send a signal to the async thread upon it’s acquisition. However this is totally inefficient since we’re doing even more work than the pure threaded solution.
Async algorithms never use blocking locks ? But then how do unrelated async drivers synchronize with each other ?
“Async algorithms never use blocking locks ?”
The async model should only ever block when there’s no IO to handle. At least in principal, it should never block at any other time.
“But then how do unrelated async drivers synchronize with each other ?”
They can communicate using the same IO mechanisms used elsewhere.
That’s just a purist view, in practice it probably wouldn’t be a big deal if they infrequently blocked on strictly momentary critical section locks.
Edited 2011-05-26 17:54 UTC
Alright, so “pure” async is about more than just nonblocking calls for the caller and an event queue for the handler. That being said, I totally understand the idea of not blocking with async.
Edited 2011-05-26 20:10 UTC
“Alright, so ‘pure’ async is about more than just nonblocking calls for the caller and an event queue for the handler.”
That’s if we take the concept to it’s extreme conclusion, obviously we don’t strictly have to. As with anything, there are tradeoffs.
It’d be nice if devs had more experience with async IO models. Many jump to the conclusion that they need MT since it’s what they know (and sometimes all that’s offered by their platforms – talking to you Java).
I guess we’ve taken this topic to it’s conclusion.
A la prochain fois.