multi-core software

Jeff M. massung at
Sun Jun 7 10:23:56 EDT 2009

On Jun 7, 1:56 am, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "Jeff M." <mass... at> writes:
> > > > Even the lightest weight
> > > > user space ("green") threads need a few hundred instructions, minimum,
> > > > to amortize the cost of context switching....
> > There's always a context switch. It's just whether or not you are
> > switching in/out a virtual stack and registers for the context or the
> > hardware stack/registers.
> I don't see the hundreds of instructions in that case.  
> shows GHC doing 50 million lightweight thread switches in 8.47
> seconds, passing a token around a thread ring.  Almost all of that is
> probably spent acquiring and releasing the token's lock as the token
> is passed from one thread to another.  That simply doesn't leave time
> for hundreds of instructions per switch.

Who said there has to be? Sample code below (just to get the point

struct context {
   vir_reg pc, sp, bp, ... ;
   object* stack;

   // ...

   context* next;

struct vm {
   context* active_context;

void switch_context(vm* v)
   // maybe GC v->active_context before switching

   v->active_context = v->active_context->next;

Also, there isn't "hundreds of instructions" with multiplexing,
either. It's all done in hardware. Take a look at the disassembly for
any application: one that uses native threads on a platform that
supports preemption. You won't see any instructions anywhere in the
program that perform a context switch. If you did that would be
absolutely horrible. Imagine if the compiler did something like this:

  // whatever


That would suck. ;-)

That's not to imply that there isn't a cost; there's always a cost.
The example above just goes to show that for green threads, the cost
[of the switch] can be reduced down to a single pointer assignment.

Jeff M.

More information about the Python-list mailing list