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 On May 16, 2009, at 3:00 PM, Zoltan Varga wrote:> Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at mac.com> > wrote: > Some of you may have noticed that I addedd include/llvm/System/ > Atomics.h to the repository briefly, which will be used for adding > support for threading in LLVM. > > I have tried to provided appropriate implementations of the atomic > ops (currently memory fence and CAS) for platforms we care about, > but my knowledge of these, and my ability to test them, is limited. > So, please, if you run on any less common platform, test out the > file, and send me patches to improve it if it doesn't work verbatim > on your system. > > Thanks, > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090516/6fae4db3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090516/6fae4db3/attachment.bin>
On May 16, 2009, at 10:01 PM, Owen Anderson wrote:> 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
On May 17, 2009, at 12:32 PM, Chris Lattner wrote:> 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!I'm not trying to make it required. I had provided threads-disabled versions of all the operations.> 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.After thinking about this some more, I think you're right. Trying to support every platform anyone cares about is rapidly becoming a nightmare. Setting GCC4.2 as a baseline requirement (and presumably providing a Windows implementation as well) is probably a good way to get this back to a sane amount of stuff to support. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090517/94b7c3c0/attachment.bin>