Re: Named shared memory without synchronization
<adebaene@club-internet.fr> wrote:
Is this really a stable solution?
No. I'd suggest to use `volatile' specifier, so compiler
will be aware of possibility of asynchronous changes. In
your specific case optimizer didn't kick in for whatever
reason, but I wouldn't rely on that in the future.
I do not agree : The semantic of "volatile" as defined in
the C
standard is so imprecise that it is almost useless. In any
cases,
"volatile" is NOT a guarantee when delaling with
multithreading
context.
All I wanted to say is that in order to disable optimizer
for certain variable one should use `volatile' specifier.
Definition of `volatile' is precise enough to give you
uncached access to a variable. That's why I said that
without `volatile' specifier usage of shared variable is
unstable.
Thread synchronization is another story. You _can_ build
something really simple with volatile integers, for example:
volatile int g_flag = 0;
// thread 1
g_flag = 1;
// thread 2
while(!g_flag)
{
// do something
}
However, for any serious work I would use Interlocked*
functions, too, without doubt.
As Igor has already explained, this doesn't hold true for
VC8, which
gives precise and meaningfull semantic to volatile (ie :
memory
barriers), but this is VC8-specific and is not portable.
If I understood correctly, original poster needs much less
than memory barriers. All is required that shared variable
won't be cached by optimizer. `volatile' specifier is
sufficient for that task.
Alex