[LLVMdev] About clock and wait instruction

[Chris Lattner]

Reid Spencer <reid at x10sys.com> wrote:

>> Currently we do little more than let programs use pthreads or some
>> other threading library, but we do intend to eventually add first-class
>> synchronization support to LLVM.  This will develop as there is a need.

> There _is_ a need :) .. let me know if I can help in this area, it is
> one of the key things I need for XPS.  I can get by with pthread for now
> but would much rather LLVM supported some minimal set of thread/synch
> primitives.

Ok, cool.  Well if you'd like to work on this here is my wishlist on the
issue.  It would be nice if you could think about this and put together a
short proposal for an LLVM extension to support it (probably consisting of
LLVM intrinsic functions).  After the sync issues are handled, we can
start thinking about the higher-level issues like thread creation,
joining, cancellation, etc.

* I'd like to be able to support "arbitrary" sorts of synchronization in
  LLVM.  For example, you should be able to _implement_ the various
  'light-weight synchronization' constructs with the LLVM constructs.
  Also, things like read-copy-update should be implementable, as well as
  the typical mechanisms people use to make things like COW strings
  efficient.
* Being able to _implement_ the synchronization parts of a pthreads
  library entirely with LLVM primitives is important (in time, we want to
  be able to implement the entire thing (for the LLVA project), but
  starting with sync operations makes sense).
* If the library would impact high-level parallelism mechanisms like MPI,
  that should be thought about perhaps.
* Being able to support languages like Java is important, but I think
  Java just exposes a subset of pthreads functionality (recursive locks
  and condvars).
* Given native code generator support, it should be implementable on all
  reasonable targets.
* Exposing an abstract-enough layer is important.  We want to be able to
  eliminate extraneous synch operations from programs that don't need it.
  This, however, means that the meaning of the various low-level
  operations has to be pretty clear.  This somewhat contradicts the first
  wishlist item.
* It should be as small as possible.  :)

When you get some sort of simple proposal together, please post it on
llvmdev to get feedback from people, which will hopefully ensure that it
is useful to a broad range of projects before it gets implemented. :)

If the proposal makes sense, it should be pretty trivial to implement it
in the X86/Sparc backends, but also think about how the C backend and
interpreter would handle the primitives...

Thanks!

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/