On 2013-01-28 12:48 AM, Brian Smith wrote:
Joshua Cranmer wrote:
In bug 732043, I want to add a mozilla::Atomic class
that lets us use C++11 atomics where available and fallback to
compiler intrinsics where C++11 atomics are not implemented
(which amounts to gcc 4.4 and Visual Studio 2010 or
On 1/27/2013 11:48 PM, Brian Smith wrote:
Joshua Cranmer wrote:
In bug 732043, I want to add a mozilla::Atomic class
that lets us use C++11 atomics where available and fallback to
compiler intrinsics where C++11 atomics are not implemented
(which amounts to gcc 4.4 and Visual Studio 2010 or
Joshua Cranmer wrote:
On 1/27/2013 11:48 PM, Brian Smith wrote:
FWIW, in cases like this, I would rather we just use the C++11 API
directly even if it means dropping support for common but
out-of-date compilers like gcc 4.4 and VS2010.
I personally prefer an API style where the memory
On Fri, Dec 14, 2012 at 12:33 PM, Joshua Cranmer pidgeo...@verizon.netwrote:
3. Similar to #2, the ideal version of a reference counter would be
mozilla::Atomicnsrefcnt, mozilla::Unordered (which would make threadsafe
refcounting cheaper on our ARM platforms if we compiled with gcc 4.6 or
Is code like this safe in the C++1 Unordered model?
Thread 1:
int x = obj-v;
obj-Release();
Thread 2:
obj-Release();
where obj's destructor trashes obj-v.
The potential hazard is if thread 1's obj-Release() atomic decrement is
reordered to run before the obj-v load has completed,
On 12/14/12 1:48 AM, Justin Lebar wrote:
FWIW, I once tried changing all of our atomic string refcounting to
non-atomic operations and could not eke out a performance (or
stability) difference on x64. This was despite the fact that I was
able to generate profiles where the atomic string
6 matches
Mail list logo
