Linked by Hadrien Grasland on Wed 25th May 2011 05:42 UTC
Hardware, Embedded Systems 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.
Permalink for comment 474499
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

"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.

Reply Parent Score: 2