On 3/22/2013 4:52 PM, you wrote:
When threads are writing to bit fields, there are mutex locks. It's an
existing condition and it worked well from many years. So I wonder if
there is a way to get around the "false" errors from Helgrind? Thanks.
Without seeing the precise code that is creating the locks and accessing
the variables, it is hard to be certain that it is in fact safe. Can
you reduce it to a minimal sample? Are you using only POSIX pthread
primitives, or properly describing the lock primitives you are using?
If you can create a small sample with no proprietary code that exhibits
the problems you are seeing, someone with more experience using Helgrind
(or one of the tool's authors) can comment on it.
One thing that may be causing problems is that Valgrind and its analysis
tools (such as Helgrind) are working with assembly language, not a
high-level language such as C. Thus it does not know the intent of your
code - that there are two independent sets of bit fields in the record,
and that threads will never (or at least should never) modify the
"wrong" bit fields. It only sees that a data word was written by one
thread, but another thread still has an old value. The question then
becomes "why does Helgrind think your code has an old value somewhere?"
--
David Chapman [email protected]
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
