On Monday 27 August 2012 15:25:14 Marc Mutz wrote:
If atomic loads and stores on x86 are implemented with a volatile cast,
then the compiler can't reorder stuff around them, either. Not more than
with a std::atomic, at least. QAtomic does that. For load-relaxed, Thiago
thinks that a normal
On 01/23/2013 03:08 PM, David Faure wrote:
I was talking to Julian about this again today, and he pointed me to this
writeup:
http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming
We're looking at how to silence valgrind about Qt atomic
On Jan 23, 2013, at 8:08 AM CST, David Faure wrote:
On Monday 27 August 2012 15:25:14 Marc Mutz wrote:
If atomic loads and stores on x86 are implemented with a volatile cast,
then the compiler can't reorder stuff around them, either. Not more than
with a std::atomic, at least. QAtomic does
On 01/23/2013 04:22 PM, Dave Goodell wrote:
If you don't want to write inline assembly, this might be your best bet.
But on TSO systems like x86, you only need a compiler barrier.
In x86 inline assembly syntax, this looks like:
__asm__ __volatile__ ( ::: memory )
This prevents GCC (and
On Jan 23, 2013, at 9:55 AM CST, Thiago Macieira wrote:
On quarta-feira, 23 de janeiro de 2013 09.22.49, Dave Goodell wrote:
If you don't want to write inline assembly, this might be your best bet.
But on TSO systems like x86, you only need a compiler barrier. In x86
inline assembly
On Jan 23, 2013, at 10:33 AM CST, Dave Goodell wrote:
Julian/Bart/etc. may have more to add here. I remember having trouble with
annotating load-acquire/store-release in the past. Here's the (only
partially helpful) thread on the topic:
Sorry for the extra email. I accidentally whacked
For a different approach to this issue: if helgrind can't reliably detect
atomic operations, as discussed before, and if VALGRIND_HG_ENABLE_CHECKING is
broken (see my previous email in this thread), then a simple solution is to
add suppressions.
{
QBasicAtomicPointer_load
Helgrind:Race
Hi, I'm finally coming back to this issue.
On Sunday 26 August 2012 12:49:27 Julian Seward wrote:
I'm not sure what can be done then, to avoid a helgrind warning.
If you can guarantee that // some calculation goes here touches only
thread-local state, then there is only a race on sharedInt
On Tuesday, August 28, 2012, Patrick J. LoPresti wrote:
On Sun, Aug 26, 2012 at 2:06 AM, David Faure fa...@kde.org wrote:
Marc Mutz said
The standard says it's racy, but the implementation of
std::atomic::load(memory_order_acquire) won't look different. Simple
reads and writes on x86 are
On Sunday 26 August 2012 12:53:41 Marc Mutz wrote:
On Sunday August 26 2012, David Faure wrote:
On Sunday 26 August 2012 11:28:06 Julian Seward wrote:
On Sunday, August 26, 2012, David Faure wrote:
Thiago expects that helgrind can't autodetect this case and that
helgrind- macros
On Sun, Aug 26, 2012 at 2:06 AM, David Faure fa...@kde.org wrote:
Marc Mutz said
The standard says it's racy, but the implementation of
std::atomic::load(memory_order_acquire) won't look different. Simple reads
and writes on x86 are already sequentially consistent.
I do not think this is
On Sunday 26 August 2012 01:30:43 David Faure wrote:
On Saturday 25 August 2012 22:43:58 Julian Seward wrote:
Or maybe Qt really is racey
Bingo :)
OK, maybe not. Turns out the code runs as intended by the Qt developers.
Marc Mutz said
The standard says it's racy, but the implementation of
On Sunday, August 26, 2012, David Faure wrote:
Thiago expects that helgrind can't autodetect this case and that helgrind-
macros markup is needed in Qt, I'm fine with adding that if you guys agree
-- after you show me how by modifying the attached example :-)
IIUC then,
On Sunday 26 August 2012 11:28:06 Julian Seward wrote:
On Sunday, August 26, 2012, David Faure wrote:
Thiago expects that helgrind can't autodetect this case and that helgrind-
macros markup is needed in Qt, I'm fine with adding that if you guys agree
-- after you show me how by modifying
I'm not sure what can be done then, to avoid a helgrind warning.
If you can guarantee that // some calculation goes here touches only
thread-local state, then there is only a race on sharedInt itself. In
which case, use VALGRIND_HG_{DISABLE,ENABLE}_CHECKING to disable reporting
on the relevant
How do I tell helgrind that some atomic operations on integers are OK?
A suppression like this works, but it would make helgrind more useful to all Qt
users if either atomic operations were handled automatically, or if this was
added to valgrind's own suppressions.
{
On 08/25/12 08:45, David Faure wrote:
How do I tell helgrind that some atomic operations on integers are OK?
A suppression like this works, but it would make helgrind more useful to all
Qt users if either atomic operations were handled automatically, or if this
was added to valgrind's own
On Saturday, August 25, 2012, David Faure wrote:
How do I tell helgrind that some atomic operations on integers are OK?
[...]
Without looking in more detail at this, it is difficult to tell if that
is really the right question to ask.
Helgrind treats atomic operations (atomic
18 matches
Mail list logo
