Re: Volatile + multithreading
- From: "wxs" <w@xxxxx>
- Date: Thu, 21 Apr 2005 17:43:19 -0400
One statement wrong in here
>Using volatile on any class field or global seems to have no impact because
>it seems the compiler will ALWAYS read or write the variable directly from
>memory for any variable that is not a parameter variable or a method
>variable
"wxs" <w@xxxxx> wrote in message
news:eEavMlrRFHA.3716@xxxxxxxxxxxxxxxxxxxxxxx
> Is volatile really of any use with the current compilers VS 2003?
>
> The only time I think volatile may do something on code is if it is used
> on a parameter value or on a method variable. Using volatile on any class
> field or global seems to have no impact because it seems the compiler will
> never not read or write the variable directly from memory for any variable
> that is not a parameter variable or a method variable.
>
> Thinking more closely on this it kind of makes sense otherwise all
> multithreaded code would potentially be in jeopardy. Think what would
> happen if you really did have to apply volatile to avoid a variable being
> put into a register. In multithreaded code that would many virtually any
> variable you use that you access from another thread would require having
> volatile applied. locks, and locking do not protect you, as the compiler
> doesn't know anything about lock calls (even if it did, it wouldn't matter
> because if you called a locking/synchronization object indirectly through
> a virtual members or just multiple calls there is no way it would know
> there could be an issue until runtime which is too late.)
>
> think of a case where I do the following.
> class MyClass
> {
> bool m_bDone;
>
> MyMethod()
> {
> //What if compiler put m_bDone in register AX here
> AcquireCriticalSection()
> while(!m_bDone) //What happens if m_bDone was preloaded in a register
> earlier and now this is while(!AX)
>
> {
> //Do work here
> }
> ReleaseCriticalSection();
> }
>
> //.. Other methods here
>
> }
>
> This means that locks would not protect you, only the keyword volatile
> would. This would require you to put volatile on every variable used in a
> way that mattered.
>
> It seems the compiler writers must have known this and instead imposed the
> rule that only parameter variables and stack variables (method variables)
> can be optimized into registers since no one is likely to pass the address
> to one of those to be used by another thread. This I believe prevents a
> majority of the multithreading issues that could have resulted from
> optimization. I thought there might be a compiler option that would
> optimize this so you would require this. It seems there is a compiler
> option for aliasing that seems to suggest enabling it will require putting
> volatile everywhere, but when I tried it, it still did not optimize any of
> the non-stack method/parameter variables into registers that I could see.
>
> I'm sure some compiler or platform does support it, and I guess it's
> possible Microsoft compiler might support it too eventually, but if they
> enabled it by default it would break a whole heck of a lot of code. So it
> seems that volatile on Intel platforms with the Microsoft compiler by
> default really don't require volatile in almost any circumstance.
>
>
>
> Or am I missing something?
>
>
.
- References:
- Volatile + multithreading
- From: wxs
- Volatile + multithreading
- Prev by Date: Load icon in a ImageList control
- Next by Date: Re: Volatile + multithreading
- Previous by thread: Volatile + multithreading
- Next by thread: Re: Volatile + multithreading
- Index(es):
Relevant Pages
|
