[LLVMdev] RFC: Atomics.h
Török Edwin
edwintorok at gmail.com
Sun May 17 10:54:23 PDT 2009
On 2009-05-17 20:08, Owen Anderson wrote:
>
> 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.
There is a static mutex implementation in Boost, that uses
PTHREAD_MUTEX_INITIALIZER when pthread is available, and uses
InterlockedCompareAndExchange on win32 (no mutexes, or criticalsections):
https://svn.boost.org/trac/boost/browser/trunk/libs/regex/src/static_mutex.cpp
This may be useful too:
https://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/once.hpp
https://svn.boost.org/trac/boost/browser/trunk/boost/thread/pthread/once.hpp
It doesn't use any inline assembly.
Best regards,
--Edwin
More information about the llvm-dev
mailing list