Comments on: Coroutines, pt. 2

By: Jens Alfke

Jens Alfke — Thu, 08 May 2008 21:04:57 +0000

Warren — Thanks for the link! Yes, I’ve heard about protothreads-style designs before; they exploit a weird (ab)use of C switch statements that’s called a “Duff’s Device”.

The problem with these is that none of the local variables in your functions are preserved across context switches! It’s really just using a ‘goto’ to jump back into the middle of the function when control returns. They’re definitely as light-weight as you can get, but I’ll bet they’re very hard to program for.

By: http://warrenharris.myopenid.com/

http://warrenharris.myopenid.com/ — Thu, 08 May 2008 17:27:09 +0000

Eigenclass had a good survey recently of lightweight threads packages: http://eigenclass.org/hiki/threadring-with-protothreads

By: Jens Alfke

Jens Alfke — Sun, 04 May 2008 15:21:49 +0000

E.Wing — Yes, I've been interested in Lua for a while. In the PubSub framework we used Lua as the templating engine for converting news articles into HTML pages for Safari RSS to display. I don't believe Lua's coroutines affect the native (C) execution context, though. They just switch Lua's interpreted stack around. So calling back into native code from a Lua coroutine wouldn't be anything like using native coroutines.

By: E. Wing

E. Wing — Sun, 04 May 2008 10:40:28 +0000

Probably not quite what you were thinking, but have you looked at Lua? Coroutines were added in Lua 5. Lua is written in 100% ANSI C, so it’s extremely portable. Since Lua’s strength is as an embedded language, you could consider factoring your code such that you invoke Lua to take the responsibility of directly creating/managing coroutines, and then have each coroutine call back into Obj-C to do your real work.

Chapter 9 of the Programming in Lua Book (version 5.0 free online) covers different examples of using coroutines in Lua.

By: Wim Leers

Wim Leers — Sun, 04 May 2008 07:17:03 +0000

We’ve had to implement our own super light-weight threading library (just cooperative of course, through a “yield” call) by using ucontext as a university assignment. Cool to see that the pros really are doing this kind of stuff as well :)

Anyway, I don’t remember the details, but I do remember that pthreads has a significant overhead when compared to ucontext.

By: Sam Roberts

Sam Roberts — Sat, 03 May 2008 17:19:27 +0000

I think pthreads have a lot more overhead than ucontext. You might not be interested in huge numbers of co-routines, but when you create a thread you get its /proc entries, it gets references to all the file descriptors, preemptive context switching might occur during floating point operations, which forces saving the FPU state. From a pure size, do a sizeof(uncontext_t) and then imagine all the places in the kernel that know about your threads… Also, the kernel tracks use/system space execution time for threads.

That said, it hard to imagine coros NOT wreaking havoc on the obj-c runtime!

By: Jens Alfke

Jens Alfke — Sat, 03 May 2008 17:02:00 +0000

Oho! I had been thinking about using a lock per thread, but your idea of a numeric ID on a single lock is very clever. Thanks!

(And yeah, probably no need to use pthreads API if I can do it with Foundation classes.)

By: Jens Ayton

Jens Ayton — Sat, 03 May 2008 16:57:02 +0000

I believe the shared lock technique is also used for Thread Manager threads under OS X, for non-tutorial purposes.

At the Cocoa level, what you’re asking could be done with a condition lock. Each task would be given a numeric ID, and use that as a condition for -lockWhenCondition:. Yielding to a specific routine would be implemented on -unlockWithCondition:, and round-robin scheduling could be easily built on top of that.

I assume there’s a pthread-level equivalent to NSConditionLock, but I haven’t looked.