[Review] Coroutine : Christopher's Review

(I lost the initial review announcement.) Yes, I vote that Coroutine should be accepted into Boost! General impression of the library: Coroutine offers enormous potential for programming regimes such as communications software and embedded systems design. For example, a lightweight event/alarm-based cooperative multitasking scheduler for embedded systems can be readily implemented usingCoroutine combined with a timer resource. Oliver has selected a sensible granularity for Coroutine. It includes Boost.Context, Coroutine and the proposed Boost.Fiber. This granularity allows for fine-tuning the implementations of cooperative scheduling mechanisms while avoiding the prohibitively heavy weight of preemptive scheduling that is found in POSIX and often in implementations of the C++11 thread support library. The documentation is terse, yet complete and informative. The examples are good. The design of Coroutine is clearly thought through. In particular, the separation of Coroutine from Context allows for porting to other systems with minimal effort and maximum reliability and code re-use. How long did I work with Coroutine? I worked for about 1 week with Coroutine. In particular, I worked very intensively with Coroutine for 2 days straight. I used Coroutine with VS2010, VS2012-RC and several GNU compilers. I spent a lot of time deeply embedding Coroutine in a hard real-time system. This experience has led to the comments and suggestions shown below. Am I familiar with the regime of Coroutine? Yes. I am absolutely familiar with the regime of Coroutine. I have authored many cooperative multitasking schedulers for a variety of CPU architectures and shipped them in tens of millions of devices. Suggestions for Coroutine: I have several suggestions for Coroutine, none of which stand in the way of immediate acceptance into Boost. 1) The code may potentially benefit from some clean-up. In particular, there is a mixture of tabs and spaces in the code, possibly resulting from programming over two or more time epochs with different styles. A simple reformat will clean this up. Coroutine is desperately needed in the embedded systems community. Along these lines, I suggests some extensions. 2) There should be, let's say, a *lightweight* version (or configuration) of Coroutine for embedded systems 3) The lightweight version can not use the non-placement version of new(). The internal details of a coroutine are stored in the class as a pointer created with non-placement new(). The lightweight version could add a parameter for user-supplied memory and create the coroutine implementation details with placement-new(). 4) Furthermore, the lightweight version should not not use any exceptions whatsoever. I spent two solid hours removing all traces of exceptions while embedding Coroutine. The result was a lightweight mechanism that only costed a few kilobytes of program code. 5) We need to work together to create more contexts for different CPU architectures. The ARM(R) context that is present in Boost.Context uses several ASM operations that my ARM(R) Cortex(R)-M3 does not support. For this reason, I could not complete my benchmark. We can work on this in the future. Thank you for your efforts and good luck! Best regards, Chris.

Hello Christopher, thank you for your review Am 06.09.2012 20:38, schrieb Christopher Kormanyos:
1) The code may potentially benefit from some clean-up. In particular, there is a mixture of tabs and spaces in the code, possibly resulting from programming over two or more time epochs with different styles. A simple reformat will clean this up. OK - forgot to activate my vim scripts - I'll fix this soon
2) There should be, let's say, a *lightweight* version (or configuration) of Coroutine for embedded systems OK
3) The lightweight version can not use the non-placement version of new(). The internal details of a coroutine are stored in the class as a pointer created with non-placement new(). The lightweight version could add a parameter for user-supplied memory and create the coroutine implementation details with placement-new(). Vicente suggested to add an allocator handles allocation of the internal class - I think it ill address this issue.
4) Furthermore, the lightweight version should not not use any exceptions whatsoever. I spent two solid hours removing all traces of exceptions while embedding Coroutine. The result was a lightweight mechanism that only costed a few kilobytes of program code. Some of the exceptions are replaced by assertions (pre-conditions) - one exception 'stack_unwind' is required in order to unwind the stack. The question is how to unwind the stack without throwing exceptions. Of course there is the Itanium unwind API but not all compiler provide it (gcc does, pgi not). At least exceptions are thrown by BOOT_THROW_EXCPETION macro - you can disable it with a compiler flag.
5) We need to work together to create more contexts for different CPU architectures. The ARM(R) context that is present in Boost.Context uses several ASM operations that my ARM(R) Cortex(R)-M3 does not support. For this reason, I could not complete my benchmark. We can work on this in the future. OK - let my know which instructions are not available on Cortex-M (but it is an issue of boost.context). The usage of main stack pointer/process stack pointer could add some benefits too.
regards, Oliver

On 06.09.2012 21:01, Oliver Kowalke wrote: >> not use any exceptions whatsoever. I spent two solid >> hours removing all traces of exceptions while embedding >> Coroutine. The result was a lightweight mechanism >> that only costed a few kilobytes of program code. > 4) Furthermore, the lightweight version should not > Some of the exceptions are replaced by assertions (pre-conditions) - > one exception 'stack_unwind' is required in order to unwind the stack. > The question is how to unwind the stack without throwing exceptions. > Of course there is the Itanium unwind API but not all compiler provide > it (gcc does, pgi not). Is there a point? I was under the impression that the heavy part of exception handling is the unwind tables, so if you get rid of that, you can't use unwind anyway. Sebastian
participants (3)
-
Christopher Kormanyos
-
Oliver Kowalke
-
Sebastian Redl