Re: InterlockedExchange64
If you want a variable initialized, you should do so explicitly. Yes, it
looks like the standard guarantees they will be initialized to zero, but if
your program behavior relies on it, make it explicit as a form of
self-documentation. It costs nothing.
"Leandro Oliveira" <loliveira@gmail.com> wrote in message
news:1187044841.602686.84860@l70g2000hse.googlegroups.com...
Hi Ben,
Are u sure? Doesn?t the CRT initialize all globals with 0 before call
main()?
Best regards.
On Aug 13, 7:27 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
"Igor Tandetnik" <itandet...@mvps.org> wrote in message
news:uOuZlbf3HHA.4400@TK2MSFTNGP06.phx.gbl...
Leandro Oliveira <lolive...@gmail.com> wrote:
I am studying the InterlockedExchange64 function behavior and i think
I did sth wrong. IMO, the line that contains teh call
to ::DebugBreak() shouldn?t neve be executed. Am I right?
//////////////////////////////////////////////////////////////////////
volatile __int64 g;
unsigned __stdcall Check(void*)
{
__int64 t;
InterlockedExchange64(&t, g);
t is allocated on the stack. It's impossible for two threads to assign
to
the same variable concurrently, since each thread has its own stack and
its own copy of t. Why do you feel the need to use InterlockedExchange64
here, and not just
t = g;
? If you hope that InterlockedExchange64 somehow reads g atomically, you
are mistaken: it only assigns to t atomically (which is quite pointless
here). To perform an atomic read, do
__int64 local_g = InterlockedExchangeAdd64(&g, 0);
Additionally, it is entirely possible for the child thread to see the
uninitialized value of g, before the main thread ever writes to it.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925