Perhaps of some interest: http://www.hpl.hp.com/research/linux/atomic_ops/
Neal Becker wrote:
Perhaps of some interest:
You might also look at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html Hans Boehm's proposal seems to build upon this library you were pointing at. (Not surprisingly, since he is the author of it.) I am currently trying to prototype something along his proposal, to see how far I can get. Until now I have found some loopholes I am trying to figure out. E.g.: atomic<int> i1; atomic<int> i2; i1 = 42; // assignment is atomic i1 = i2; // assignment is not atomic ! --> should atomics be allowed to be copyable? I would say: yes and no. I would expect that the value can be transfered, but it should be semantically equivalent to: int t; t = i1; i2 = t; The current proposal as far as I can see does not address this issue. It allows for a bitwise copy by the compiler. Or : struct a4 { char c[4]; }; atomic<a4> a; Shall this be possible, if a4 is POD and has same alignment and size of a type that can be manipulated atomically? If yes, how can it be implemented? If you like we can discuss this further. Roland
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:45573FB1.70304@chello.at...
Neal Becker wrote:
Perhaps of some interest:
You might also look at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html
Hans Boehm's proposal seems to build upon this library you were pointing at. (Not surprisingly, since he is the author of it.)
I am currently trying to prototype something along his proposal, to see how far I can get.
Until now I have found some loopholes I am trying to figure out.
Here is how I define rules for my atomic<T>: Can't use any constructors, destructors, base classes, virtual functions, or anything else that violates POD requirements. Can't use any operators Atomic operation API must have static interface that operates on pointers to T as the destination of any operation. Usage is like: static foo s_foo = 0; typedef atomic<foo> atomic_foo_t; void something() { atomic_foo_t::cas<mb::storeload>(&s_foo, 0, 5); } Any thoughts on this approach?
Chris Thomasson wrote:
Here is how I define rules for my atomic<T>:
Can't use any constructors, destructors, base classes, virtual functions, or anything else that violates POD requirements.
Can't use any operators
Hmm, what is your rationale for this choice? I would have expected that you will need the POD requirements only for type T, not for atomic<T>.
Atomic operation API must have static interface that operates on pointers to T as the destination of any operation. Usage is like:
So, why then wrap as a class at all? Why not simply templated global functions? What I think is more important than making atomic<T> a POD, is making atomic<T> fail to compile if 1) sizeof(T) != sizeof(atomic_t) 2) alignment of T != required alignment of atomic_t Where atomic_t is a type that is atomic on the given platform/compiler. Roland
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:455AFA4B.7010605@chello.at...
Chris Thomasson wrote:
Here is how I define rules for my atomic<T>:
Can't use any constructors, destructors, base classes, virtual functions, or anything else that violates POD requirements.
Can't use any operators
Hmm, what is your rationale for this choice?
I would have expected that you will need the POD requirements only for type T, not for atomic<T>.
Atomic operation API must have static interface that operates on pointers to T as the destination of any operation. Usage is like:
So, why then wrap as a class at all? Why not simply templated global functions?
Humm. Good point... :^)
What I think is more important than making atomic<T> a POD, is making atomic<T> fail to compile if
1) sizeof(T) != sizeof(atomic_t) 2) alignment of T != required alignment of atomic_t
Where atomic_t is a type that is atomic on the given platform/compiler.
You could do that with meta programming. Would that be a viable option?
"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:455AFA4B.7010605@chello.at...
Chris Thomasson wrote:
Here is how I define rules for my atomic<T>:
Can't use any constructors, destructors, base classes, virtual functions, or anything else that violates POD requirements.
Can't use any operators
Hmm, what is your rationale for this choice?
What are the memory barrier characteristics' of all the operators that make store/load to/from the user provided T POD type? I would assume they are naked... How would you define them?
I would have expected that you will need the POD requirements only for type T, not for atomic<T>.
Template function API sounds better than atomic<T> class that holds a member of type T. Define a rule that states that T must be a POD, and must be a type that can be atomically modified by the target architecture. The latter can be handled with arch-specific template metaprogramming, the former can be handled with an undefined behavior clause.
participants (3)
-
Chris Thomasson -
Neal Becker -
Roland Schwarz