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 whacke
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 asse
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
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
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 atomi
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
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 shar
On Tuesday, August 28, 2012, Patrick J. LoPresti wrote:
> On Sun, Aug 26, 2012 at 2:06 AM, David Faure 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 alr
On Sun, Aug 26, 2012 at 2:06 AM, David Faure 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 true. Loa
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
> 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 releva
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 modif
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, QBasicAtomicInt::{loa
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 implementati
On Saturday 25 August 2012 22:43:58 Julian Seward wrote:
> Or maybe Qt really is racey
Bingo :)
I tried extracting a testcase of the problem, and it turns out that Qt5's
feature detection (which implementation to use) goes wrong, and a no-op code
path ends up being used for this particular opera
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 read-modify-wri
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
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.
{
qt5_basic_atomic_integer
19 matches
Mail list logo
