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.
Thread beginning with comment 474499
To view parent comment, click here.
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

Neolander Member since:
2010-03-08

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.

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

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.

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.

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.

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

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.

In such a case, a synchronous approach is best, since you can only process one task at a time due to mutual exclusion.

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.

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.

"IIRC, advantages of using IR are that 1/IR leds are cheap"

Colored leds are pretty cheap too.

Fair point ^^

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

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.

"and 3/There's less parasitic light in the near IR range than in the visible range."

Very possible.

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

Reply Parent Score: 1

Alfman Member since:
2011-01-28

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.

Reply Parent Score: 2