After some discussions and further coding, the external library has been
refined.
I've updated the document at http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
In a nutshell, the changes are:
1 - generic routines
=
The generic version routines for arbitrary sized objects were
unimplem
On 10/05/2011 10:44 AM, Jeffrey Yasskin wrote:
Yes, that's what I'm suggesting. The rule for 'volatile' from the
language is just that "Accesses to volatile objects are evaluated
strictly according to the rules of the abstract machine." If the
instruction-level implementation for a 16-byte atomi
On Wed, Oct 5, 2011 at 5:49 AM, Andrew MacLeod wrote:
> On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
>> I see two ways out:
>> 1) Say that accessing a non-volatile atomic through a volatile
>> reference or pointer causes undefined behavior. The standard doesn't
>> say that, and the casts are imp
On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
If, as the document proposes, "16 byte volatile will have to call the
external rotines, but 16 byte non-volatiles would be lock-free.", and
the external routines use locked accesses for 16-byte volatile
atomics, then this makes the concurrent access
On Fri, Sep 30, 2011 at 1:36 PM, Andrew MacLeod wrote:
> I've been working on GCC's C++11 atomic implementation. In discussions with
> Lawrence, I've recently discovered a fundamental change in what libstdc++-v3
> is likely to provide as far as an implementation.
>
> Previously, header files provi
On Mon, 3 Oct 2011, Andrew MacLeod wrote:
> On 10/03/2011 01:31 PM, Richard Henderson wrote:
> > On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
> > > http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
> >
> > >__atomic_store (size_t obj_size, T *mem, T val, enum memory_model
> > > model)
> > I don't
On 10/03/2011 10:54 AM, Andrew MacLeod wrote:
> its a library call for arbitrary sized objects... C++ can have any
> class declared atomic, so it doesn't have to map to one of those
> optimized lock-free routines.
Ah, I get it now. Ew.
r~
On 10/03/2011 01:31 PM, Richard Henderson wrote:
On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
__atomic_store (size_t obj_size, T *mem, T val, enum memory_model model)
I don't like this. I really cannot imagine any situation for which the
comp
On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
> http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
> __atomic_store (size_t obj_size, T *mem, T val, enum memory_model model)
I don't like this. I really cannot imagine any situation for which the
compiler can't resolve SIZE to a compile-time constant
On Sat, 1 Oct 2011, Andrew MacLeod wrote:
Ah ok, I had understood:
* if __atomic_store_8 is inlined on line 18, it should also be inlined
on line 42
when instead it is:
* we can't have a locked addition and a lock-free subtraction (hence
the __atomic_is_lock_free which only takes a size a
On Sat, 1 Oct 2011, Andrew MacLeod wrote:
On 10/01/2011 02:55 AM, Marc Glisse wrote:
"The compiler must ensure that for any given object, it either ALWAYS
inlines lock free routines, OR calls the external routines. For any given
object, these cannot be intermixed."
Why? You give an example
On 10/01/2011 02:55 AM, Marc Glisse wrote:
"The compiler must ensure that for any given object, it either ALWAYS
inlines lock free routines, OR calls the external routines. For any
given object, these cannot be intermixed."
Why? You give an example explaining why it is fine to link 386 and
On Fri, 30 Sep 2011, Andrew MacLeod wrote:
I've been working on GCC's C++11 atomic implementation.
Cool!
In discussions with
Lawrence, I've recently discovered a fundamental change in what libstdc++-v3
is likely to provide as far as an implementation.
Previously, header files provided a c
I've been working on GCC's C++11 atomic implementation. In discussions
with Lawrence, I've recently discovered a fundamental change in what
libstdc++-v3 is likely to provide as far as an implementation.
Previously, header files provided a choice between a locked or a
lock-free implementation,
14 matches
Mail list logo
