On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote:> Owen Anderson 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. > > Just out of curiosity, is there a design document somewhere for the > plan > for threading?Not as yet. Chris may have ideas in this direction, but I don't think they're been written down anywhere. For now, I'm just trying to enhance the thread-safety of some obviously unsafe pieces of code.> Also, atomic ops are usually pretty low level things used for > nonblocking algorithms or to build higher level locking constructs. Is > that the plan here too? It seems like you'd want to avoid anything too > fancy since LLVM has to run on so many different architectures with > their variety of memory semantics, etc.I totally agree. However, at least one case of thread-unsafety (ManagedStatic), has proven very-difficult-to-impossible to implement correctly without using lower-level operations. --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/20090516/37f0253c/attachment.bin>
Hi Owen, perhaps you could post a little testsuite for the atomic ops. I would be happy to run them on various machines. I have access to a bunch of multi-processor machines, unfortunately all x86 or x86-64. I also have access to single-processor alpha, arm, g5, mips and sparc64 machines. Ciao, Duncan.
Owen Anderson wrote:> > On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > >> Also, atomic ops are usually pretty low level things used for >> nonblocking algorithms or to build higher level locking constructs. Is >> that the plan here too? It seems like you'd want to avoid anything too >> fancy since LLVM has to run on so many different architectures with >> their variety of memory semantics, etc. > > I totally agree. However, at least one case of thread-unsafety > (ManagedStatic), has proven very-difficult-to-impossible to implement > correctly without using lower-level operations. >Yes, double-checked locking is a pain. There's a C++ safe implementation in http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html in the "Making it work with explicit memory barriers" section. As far as I know, it is still considered to work. Luke> --Owen > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On May 17, 2009, at 5:23 AM, Luke Dalessandro wrote:> Owen Anderson wrote: >> >> On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: >> >>> Also, atomic ops are usually pretty low level things used for >>> nonblocking algorithms or to build higher level locking >>> constructs. Is >>> that the plan here too? It seems like you'd want to avoid anything >>> too >>> fancy since LLVM has to run on so many different architectures with >>> their variety of memory semantics, etc. >> >> I totally agree. However, at least one case of thread-unsafety >> (ManagedStatic), has proven very-difficult-to-impossible to implement >> correctly without using lower-level operations. >> > > Yes, double-checked locking is a pain. There's a C++ safe > implementation > in > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > in the "Making it work with explicit memory barriers" section. As > far as > I know, it is still considered to work.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. --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/907801f3/attachment.bin>