[LLVMdev] About clock and wait instruction
sabre at nondot.org
Thu Dec 18 23:50:02 PST 2003
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
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
* 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
* Given native code generator support, it should be implementable on all
* 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
* 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...
More information about the llvm-dev