Linked by Hadrien Grasland on Fri 27th May 2011 11:34 UTC
General Development After having an interesting discussion with Brendan on the topic of deadlocks in threaded and asynchronous event handling systems (see the comments on this blog post), I just had something to ask to the developers on OSnews: could you live without blocking API calls? Could you work with APIs where lengthy tasks like writing to a file, sending a signal, doing network I/O, etc is done in a nonblocking fashion, with only callbacks as a mechanism to return results and notify your software when an operation is done?
Permalink for comment 474844
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

"Actually this is a very old topic."
Yes, thanks for the links. Interesting.

In the second paper, I give them credit for seriously addressing the criticisms facing MT programming. However I feel they failed make a compelling case.


"Criticism: Many attempts to use threads for high concurrency have not performed well. We don’t dispute this criticism; rather, we believe it is an artifact of poor thread implementations..."

Instead of OS threads, they suggest using user-space threads, but it's a bit of a cop out since it ignores the distinction between blocking IO and heavy CPU utilization.

"Criticism: Thread synchronization mechanisms are too heavyweight. Event systems often claim as an advantage that cooperative multitasking gives them synchronization 'for free,' since the runtime system does not need to provide mutexes, handle wait queues, and so on. However, Adya et al. show that this advantage is really due to cooperative multitask-
ing (i.e., no preemption), not events themselves; thus,
cooperative thread systems can reap the same benefits"

First, I disagree with the statement that the async model is not responsible for eliminating synchronization, without a doubt it is because async callbacks are inherently atomic. However I agree that non-preemptive threads will eliminate the need for synchronization in certain threads since that code would also be executed atomically on a single CPU.

However I don't think either of the assumptions will generally hold true with modern MT programming.


"Criticism: Thread stacks are an ineffective way to manage live state. Threaded systems typically face a tradeoff between risking stack overflow and wasting virtual address space on large stacks. Since event systems typically use few threads and unwind the
thread stack after each event handler, they avoid this
problem. To solve this problem in threaded servers, we
propose a mechanism that will enable dynamic stack
growth..."

Ok, I'm thinking maybe they want to garbage collect unused stack pages, especially on 64bit systems where virtual memory addresses are abundant...

"Using a compiler analysis, we can provide an upper bound on the amount of stack space needed when calling
each function; furthermore, we can determine which call sites may require stack growth. Recursive functions and function pointers produce additional challenges, but these problems can be addressed with further analyses."

Are these guys serious? In the async model, this problem is naturally avoided. If this is the best argument these guys have, then async clearly wins on the stack argument.

They don't specifically talk about the race conditions that come about with MT except to say that compilers should be improved to improve thread safety.


"This result shows that a well-designed thread package can achieve the same scaling behavior as a well-designed event system"

In the end, they can only demonstrate that their MT scales the same as the async code. However...


"The performance degradation for both Knot-A and Haboob is due to the poor scalability of poll(). Using the newer sys epoll system call with Knot avoids this problem and achieves excellent scalability. However, we have used the poll() result for comparison, since sys epoll is incompatible with Haboob’s socket library."

From my reading, it sounds like they did not use the more scalable epoll mechanism for either the threaded or async tests. Obviously this will have a greater negative impact on the async benchmark since poll passes in thousands of sockets per call. This would give their MT version a huge unfair advantage.

Does anyone else read it that way? The epoll version is notably absent from the graph.

Is it possible they deliberately left out an async epoll version because it outperformed their MT version?

Edited 2011-05-27 17:15 UTC

Reply Parent Score: 2