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 474729
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

"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

Reply Parent Score: 2

Neolander Member since:

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

Reply Parent Score: 1

Alfman Member since:

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

Reply Parent Score: 2