------- Comment #12 from tomash dot brechko at gmail dot com 2007-10-14 14:15
-------
I wish I could reopen the bug, but the only option I see is "Leave as
UNCONFIRMED".
(In reply to comment #9)
> So it sounds like you don't any thing about threading programming. People
> have
> to use mutexes and such to get safe code storing/accessing in globals no
> matter
> what, even if it looks like it is thread safe or not because of the way
> threads
> act. I don't see how this is different from knowning when programs access
> memory in some random way.
I would agree with Jakub, his example is perfectly thread-safe. The point is
not about reading memory in random ways, but about random writes. Consider the
following adjustment:
void
foo (int x, int y, int access_v)
{
int i;
for (i = 0; i < 100; i++)
{
if (access_v && i > x)
v = y;
}
}
Now I would say that the call to foo(a, b, 0) doesn't require any mutex, no
matter what. The fact that v is mentioned _lexically_ doesn't change anything:
for access_v == 0 (or for x >= 99, as in the original example), v = y; is
simply a dead code. You don't have to have a mutex for any variable just
because it is _mentioned_ in the code.
And the essence of this bug report is that gcc chooses to unconditionally write
to variables that are simply lexically mentioned but otherwise aren't accessed
during execution. This is wrong when both foo(a, b, 0) and foo(a, b, 1)
calls are mixed, and also may harm SMP performance when there are only foo(a,
b, 0) calls: storing the value back to v may flush the cache if the hardware
doesn't detect that the stored value is the same (I'm not sure if there are
such architectures).
Please reconsider this report.
--
tomash dot brechko at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomash dot brechko at gmail
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
