OK, I've enhanced Atomic.h by pulling in a bunch of implementations from libatomic_ops, and others that I could figure out on my own.
Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME PATCHES IF IT DOESN'T WORK! Similarly, if you think the implementation could be improved for your platform, send me a patch.
I know that Sparc doesn't work currently (no CAS implementation yet), and I'm a little unsure about the ARM version, so it'd be great if gurus for those platforms could look at them.
Owen, I would really rather that you didn't take this path. Threading support in LLVM should always be optional: it should be possible to use LLVM on systems where we don't have support for threading operations. Indeed, some systems don't support threads!
Given that, I think it makes sense to start out the atomics operations very simple: just make them work for compilers that support GCC 4.2's atomics. Since things will be changing quickly initially, this makes it easy to prototype and build things out, and this also avoids pulling in an external library with a (compatible but) different license.
In practice, I think a huge chunk of the community will be served when LLVM supports GCC 4.2 atomics + a windows implementation. I don't see a reason to make things any more complex than that. Since llvm-gcc supports atomics, someone doing development on a supported architecture can just build llvm-gcc single threaded, which provides them with a compiler that supports atomics on their platform.
Our problems are actually deeper than that, because we need to interact well with static constructors. This means that we can't use a mutex with a non-constant initializer, or else we can't depend on it being properly initialized before the ManagedStatic is accessed. While this would be possible with pthread mutexes, I know of no good way to do it for Windows CRITICAL_SECTION's.
Actually, global static constructors are evil and should be eliminated. No static constructors should do anything non-trivial, and it is essential that ManagedStatic *not have a constructor*. That is its entire design point. However, ManagedStatic should theoretically pretty simple with double checked locking. The observation is that llvm_shutdown() can only be called on one thread, but that lazily initialization of data structures can happen from multiple threads. This means that the "get" operation should look something like this (an suitably fenced version of):
if (Ptr == 0) {
lock();
if (Ptr == 0)
init();
unlock();
}
Also, I see no reason why the lock needs to be per-object. Just use a heavy weight global "pthreads" lock in the .cpp file.
When you get back to hacking on ManagedStatic, please define this in one method, not duplicated in ->, *, etc.
-Chris
