Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Another newbie question (FAQ?): Cilk-like threading?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-09-27 (20:04)
From: Brian Hurt <brian.hurt@q...>
Subject: [Caml-list] Another newbie question (FAQ?): Cilk-like threading?

Sticking my head up yet again: are there any plans to add cilk style 
threading to Ocaml?


For more info on Cilk.  But the short introduction: Cilk introduces the
idea of what you might consider "super light weight" threads, which act in
many ways like functions.  You do not call these functions, you spawn
them.  Spawning one of these cilk functions costs about 10x the cost of a
normal function call.

In the uniprocessor case, the spawning works exactly like a normal
function call.  The "parent" spawning thread (calling function) stops
execution and the "child" spawed thread (called function) starts
execution.  When the child thread exits (returns), the parent thread
resumes execution.  Only one "real" (Java- or Posix- thread) is actually
created.  It's in the multiprocessor case that it's interesting.  Here
you'd spawn multiple worker threads (one per CPU), and another worker
thread could come along and start executing the parent thread (calling
function) in parallel to the child thread (called function).  This is what
the extra overhead of spawning vr.s calling is for.

How this works in practice is that the code spawns bazillions of these
cilk "threads".  At process start up, the work is split up until every CPU
has work to do- then the extra threads just work like somewhat heavy
procedure calls.  All the programmer has to do is make sure he spawns
enough processes.  And it's safe to be aggressive with spawning, because
extra (unnecessary) spawns aren't that expensive.  This allows the same
binary executable to efficiently take advantage of a single CPU or
hundreds to thousands of CPUs.

Note this isn't a do-all end-all of threading.  For example, cilk threads
don't deal well when you have contention and need mutual exclusion (or
some other form IPC).  It works best when each thread produces it's own
output without affecting the other threads.  Having cilk functions sharing
global data or modifying data structures passed in as arguments can cause 


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: