This is the mail archive of the
mailing list for the GCC project.
Re: Optimization of conditional access to globals: thread-unsafe?
- From: Darryl Miles <darryl-mailinglists at netbauds dot net>
- To: skaller <skaller at users dot sourceforge dot net>
- Cc: Samuel Tardieu <sam at rfc1149 dot net>, Richard Guenther <richard dot guenther at gmail dot com>, Dave Korn <dave dot korn at artimi dot com>, Bart Van Assche <bart dot vanassche at gmail dot com>, Florian Weimer <fw at deneb dot enyo dot de>, Andrew Haley <aph-gcc at littlepinkcloud dot com>, gcc at gcc dot gnu dot org, Andrew Pinski <pinskia at gmail dot com>, Tomash Brechko <tomash dot brechko at gmail dot com>, Robert Dewar <dewar at adacore dot com>
- Date: Mon, 29 Oct 2007 12:17:52 +0000
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <02a401c81973$bd1a73e0$2e08a8c0@CAM.ARTIMI.COM> <20071028165917.GA19392@owl.midgard.homeip.net> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Ah .. ok I think I finally see. Thanks! The code ensures
well definedness by checking the establishment of the
required invariant and dynamically chosing whether or not
to do the access on that basis .. and the optimisation
above defeats that by lifting the access out of the
In the single threaded case the lift works because it
relies on sequential access, which is the only possibility
for a single thread.
But this is clearly not a similar case. There is a clear
read-modify-write cycle taking place (-= operator), and you describe the
problem in a way that a decrement with the value of zero is allowed.
The problem domain that is atomic read-modify-write is not the same as a
atomic assignment, which is the basis of the original issue. More over
the original issue was a write access to variable where none was
described in the code for that given circumstance.
Along the lines of my my first post to this thread, if you want atomic
read-modify-write then you are doing to have to create your
atomic_int_dec(int *intptr) function, or atomic_int_sub(int *intptr, int
value) which makes uses of IA32 CPU lock prefix instructions. But for
many other platforms (almost all RISC) you are going to have to obtain a
mutex lock then perform a 'load from memory to register', 'substract
value', 'store to memory from register'.