Linked by Hadrien Grasland on Wed 25th May 2011 05:42 UTC
Thread beginning with comment 474593
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.
RE[4]: To continue the old discussion...
by Neolander on Thu 26th May 2011 08:27
in reply to "RE[3]: To continue the old discussion..."
RE[5]: To continue the old discussion...
by Alfman on Thu 26th May 2011 17:53
in reply to "RE[4]: To continue the old discussion..."
"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





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.