Chandon's blog

Hybrid Threads: GSoC Project Results

I proposed a pretty ambitious Google Summer of Code project this year. Although I didn't manage to do everything I hoped, I did manage to get a useful subset of threading functionality working in the gsoc_threads branch. In this blog post I will describe what I have working and what more needs to be done.

Moving to multiple OS threads

Now that I have the basic green threads (Task) API basically working, it's time to start mixing in OS threads. I plan to do that in two steps: First I'm going to use OS threads to solve the key issue with the green threads implementation - blocking IO. The result of this will be basically equivilent to CPython threads-with-GIL. The second step - real parallel thread execution - will have to wait for after GSoC pencils down.

Green Threads: A Classic Example

Now that I have green threads basically working with the API functionality I discussed in my last blog post, I've been working on coming up with tests/examples that clearly demonstrate both how green threads in Parrot work and that they work as advertised. With that goal in mind, this blog post is about a classic concurrent programming example: The Sieve of Eratosthenes.

Green Threads: The Task API

Now that I have pre-emptive task switching between green threads basically working, I need to figure out what the API to interact with them wants to look like. Additionally, I need to clean up this scheduler thing that I've mauled in order to make the API and terminology consistent.

Green Threads and Sleeping

I've spent my Parrot time for the last week working on something I call Alarms. Alarms are like Timers, except instead of specifying a delay the user specifies when they want the Alarm to fire. This is a pretty simple concept. If the Scheduler did what I wanted, I'd be done long ago.

Cleaning up the Scheduler

In my work on Timers, I've concluded that the scheduler really is the right place for scheduling things (who would have guessed?). How the scheduler *should* work is described in pdd25. How the scheduler actually works is a bit different, and how I want the scheduler to work to implement green threads is a bit different from that...

A New Design for Timers

The next step in green threads is to make them preemptive: after one thread has run for a while, it needs to be stopped so a waiting thread can have a turn. Parrot has a mechanism for doing things after a set time called Timers which would be perfect for this. Unfortunately, they don't really work.

Threads are continuations

Parrot has Continuations. In fact, Parrot is *based* on Continuations: rather than having a call stack and stack frames, each sub call has a return continuation - a pointer back to the call frame and bytecode position to return to after the sub completes.

As the Scheme and Ruby users keep telling us, continuations are pretty neat stuff. In fact they're so neat that they give us light weight cooperative threads "for free".

How do threads fit into parrot?

(This post is to show my thinking on my GSoC project. Sorry in advance if it's not especially coherent or interesting out of context.)

Over the past week I've been examining the Parrot code to figure out how hybrid threads are going to fit in. First, if I'm going to make Parrot do stuff concurrently, I have to figure out what Parrot is actually doing at all.

Hybrid Threads

Threading systems let multiple code paths run at the same time. Why would anyone want that? Simple: impatience. It's no fun waiting for the computer to finish one thing when you want it to be doing something else.

So what are "hybrid" threads and why does Parrot need them? Well, there are two common schools of thought in building threading systems for high level language runtimes. The Java people call them "green" threads and "native" threads. As with any design tradeoff the right answer is to cheat and just take all the good properties of both options.

Syndicate content