Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > how to use volatile key word?

Reply
Thread Tools

how to use volatile key word?

 
 
Luca Risolia
Guest
Posts: n/a
 
      06-28-2012
On 28/06/2012 07:55, Juha Nieminen wrote:
> Locking is always expensive, even if no thread has to wait at any point.
>
> That's the very reason why so much research is being done on lock-free
> containers and atomic operations.


Globally speaking, with regard to the C++11 standard, atomic types may
use non-blocking locks in the implementation. The only exception is
std::atomic_flag, which is guaranteed not to use locks. This means that
lock-free data structures and are not necessarily wait-free data structures.

Writing wait-free data structures is extremely hard and even when you
get them right, you should make sure that the benefit outweighs the
cost, since the group of atomic operations used to implement them can be
much slower than non-atomic counterpart. In other words, the main reason
to write lock-free and wait-free code is to increase the potential for
concurrency, but it may well decrease overall performance.

For these reasons it's important to identify the relevant performance
aspect and profile various alternatives on the target platforms before
deciding.
 
Reply With Quote
 
 
 
 
Gerhard Fiedler
Guest
Posts: n/a
 
      06-28-2012
Mark wrote:

> On Wed, 27 Jun 2012 16:12:05 -0500, Paavo Helde
> <(E-Mail Removed)> wrote:
>
>>Mark <(E-Mail Removed)> wrote in
>>news:(E-Mail Removed) m:
>>
>>>
>>>>See e.g. http://en.wikipedia.org/wiki/Volatile_variable
>>>
>>> This page does show cases where use of the volatile keyword is
>>> necessary.

>>
>> Not sure what you mean, for C and C++ I see only discussion about
>> memory- mapped hardware. The examples about multi-thread
>> synchronization with volatile are talking about Java and C# where
>> this keyword apparently means something different.

>
> As I understand it there is still a risk of the unsafe opimizations
> which the volatile keyword would prevent.


While that's true, the memory barriers that come with synchronized
processor instructions, synchronization library functions/objects or the
new C++ synchronization mechanisms prevent these unsafe optimizations
also. That's why volatile is not necessary if you use these.

Gerhard
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      06-28-2012
On 06/28/12 08:46 PM, Juha Nieminen wrote:
> Ian Collins<(E-Mail Removed)> wrote:
>>> Anyways, if the choice is between writing 'volatile' and writing several
>>> lines of code to implement locking in a situation where locking is not
>>> needed, the choice is pretty clear.

>>
>> Until you have to run on a multi-core system....

>
> What difference would that make?


On reflection, possibly not a lot. volatile should keep the variable
out of caches and visible to the other cores.

--
Ian Collins
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      06-28-2012
Op 28-Jun-12 7:55, Juha Nieminen schreef:
> Ian Collins<(E-Mail Removed)> wrote:
>> Did you measure? In the absence of contention, the impact of locking
>> should be close to none.

>
> Locking is always expensive, even if no thread has to wait at any point.


It depends; for example on Windows critical sections have minimal
overhead on single core systems when there is no thread contention.
Basically it boils down to a (sort-of) atomic test-and-set instruction,
and only when the test fails it makes the (expensive) jump to kernel
mode to halt the thread. On multi-core systems the test-and-set
instruction gets a LOCK prefix to synchronize across cores which makes
it a bit more expensive. OTOH if you use just 'volatile' variables to
synchronize across threads in on x86 multi-core environments you would
need the LOCK prefix as well for read-modify-write operations.

> That's the very reason why so much research is being done on lock-free
> containers and atomic operations.
>
> Anyways, if the choice is between writing 'volatile' and writing several
> lines of code to implement locking in a situation where locking is not
> needed, the choice is pretty clear.


In that case you might even get away with leaving out 'volatile' as well.
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      06-28-2012
Op 28-Jun-12 21:16, Ian Collins schreef:
> On 06/28/12 08:46 PM, Juha Nieminen wrote:
>> Ian Collins<(E-Mail Removed)> wrote:
>>>> Anyways, if the choice is between writing 'volatile' and writing
>>>> several
>>>> lines of code to implement locking in a situation where locking is not
>>>> needed, the choice is pretty clear.
>>>
>>> Until you have to run on a multi-core system....

>>
>> What difference would that make?

>
> On reflection, possibly not a lot. volatile should keep the variable out
> of caches and visible to the other cores.


I don't know what the C++ 11 standard says about this but, on VS2010 it
does nothing special to keep volatile variables out of the cache.

 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      06-29-2012
Juha Nieminen於 2012年6月28日星期四UTC+8下午1時53分40秒 寫道:
> Paavo Helde <(E-Mail Removed)> wrote:
> > Juha Nieminen <(E-Mail Removed)> wrote in
> >> In a program I had a case where I was just reading an integral from
> >> one thread that was changed by another thread to signal a minor,


Well, this is the old joke of C with switches and cases not dupliating
the key value in cores to execute in parallel.



> >> unimportant effect (namely something related to updating the UI). This
> >> did not require full-fledged locking (which would have made it
> >> needlessly expensive) because if the integral had a wrong value for a
> >> split second, that wasn't really a catastrophical event.

> >
> > Out of curiosity - did you measure how much the "needlessly expensive"
> > locking was slower than using a volatile? I'm asking because I find myself
> > often in urge to invent all kind of clever tricks to bypass proper locking.

>
> No, but it was enough that the options were between writing 'volatile'
> and several lines of code using a non-standard library to implement proper
> locking, so the choice was rather clear to me.
>
> (In C++11 it might have been enough to declare the integral to be atomic,
> and it would probably have been equally fast and fully synchronized. However,
> I did not have C++11 at my disposal at that time.)




Juha Nieminen於 2012年6月28日星期四UTC+8下午1時53分40秒 寫道:
> Paavo Helde <(E-Mail Removed)> wrote:
> > Juha Nieminen <(E-Mail Removed)> wrote in
> >> In a program I had a case where I was just reading an integral from
> >> one thread that was changed by another thread to signal a minor,
> >> unimportant effect (namely something related to updating the UI). This
> >> did not require full-fledged locking (which would have made it
> >> needlessly expensive) because if the integral had a wrong value for a
> >> split second, that wasn't really a catastrophical event.

> >
> > Out of curiosity - did you measure how much the "needlessly expensive"
> > locking was slower than using a volatile? I'm asking because I find myself
> > often in urge to invent all kind of clever tricks to bypass proper locking.

>
> No, but it was enough that the options were between writing 'volatile'
> and several lines of code using a non-standard library to implement proper
> locking, so the choice was rather clear to me.
>
> (In C++11 it might have been enough to declare the integral to be atomic,
> and it would probably have been equally fast and fully synchronized. However,
> I did not have C++11 at my disposal at that time.)


I think MS did sense the need for multi-core programming in C#.

But C++ is getting old to have a kid in the C family.
 
Reply With Quote
 
Cong Wang
Guest
Posts: n/a
 
      06-29-2012
On Tue, 26 Jun 2012 at 17:04 GMT, Victor Bazarov <(E-Mail Removed)> wrote:
> On 6/26/2012 12:11 PM, 伏虎 wrote:
>> how to use volatile key word?
>>
>> Assume I have a global variable shared by two or more tasks. Do I
>> need to declare it as volatile?

>
> 'volatile' usually means that the object's value can be changed at any
> moment by some mechanism outside of your program control. When you have
> a global variable shared between parts of *your program*, that's all
> under your control, and hence doesn't need to be declared 'volatile'.
>


Right...

Also check this doc:
http://www.kernel.org/doc/Documentat...ed-harmful.txt

even though it is for kernel, it applies to user-space applications as
well.

Thanks.
 
Reply With Quote
 
Mark
Guest
Posts: n/a
 
      06-29-2012
On Thu, 28 Jun 2012 15:27:55 -0300, Gerhard Fiedler
<(E-Mail Removed)> wrote:

>Mark wrote:
>
>> On Wed, 27 Jun 2012 16:12:05 -0500, Paavo Helde
>> <(E-Mail Removed)> wrote:
>>
>>>Mark <(E-Mail Removed)> wrote in
>>>news:(E-Mail Removed) :
>>>
>>>>
>>>>>See e.g. http://en.wikipedia.org/wiki/Volatile_variable
>>>>
>>>> This page does show cases where use of the volatile keyword is
>>>> necessary.
>>>
>>> Not sure what you mean, for C and C++ I see only discussion about
>>> memory- mapped hardware. The examples about multi-thread
>>> synchronization with volatile are talking about Java and C# where
>>> this keyword apparently means something different.

>>
>> As I understand it there is still a risk of the unsafe opimizations
>> which the volatile keyword would prevent.

>
>While that's true, the memory barriers that come with synchronized
>processor instructions, synchronization library functions/objects or the
>new C++ synchronization mechanisms prevent these unsafe optimizations
>also. That's why volatile is not necessary if you use these.


We can't all rely on new features. I have to maintain code that needs
to work on a large variety of different compilers (including quite old
ones).
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

 
Reply With Quote
 
Gerhard Fiedler
Guest
Posts: n/a
 
      06-29-2012
Mark wrote:

> On Thu, 28 Jun 2012 15:27:55 -0300, Gerhard Fiedler
> <(E-Mail Removed)> wrote:
>
>>Mark wrote:
>>
>>> On Wed, 27 Jun 2012 16:12:05 -0500, Paavo Helde
>>> <(E-Mail Removed)> wrote:
>>>
>>>>Mark <(E-Mail Removed)> wrote in
>>>>news:(E-Mail Removed) m:
>>>>
>>>>>
>>>>>>See e.g. http://en.wikipedia.org/wiki/Volatile_variable
>>>>>
>>>>> This page does show cases where use of the volatile keyword is
>>>>> necessary.
>>>>
>>>> Not sure what you mean, for C and C++ I see only discussion about
>>>> memory- mapped hardware. The examples about multi-thread
>>>> synchronization with volatile are talking about Java and C# where
>>>> this keyword apparently means something different.
>>>
>>> As I understand it there is still a risk of the unsafe opimizations
>>> which the volatile keyword would prevent.

>>
>>While that's true, the memory barriers that come with synchronized
>>processor instructions, synchronization library functions/objects or the
>>new C++ synchronization mechanisms prevent these unsafe optimizations
>>also. That's why volatile is not necessary if you use these.

>
> We can't all rely on new features. I have to maintain code that needs
> to work on a large variety of different compilers (including quite old
> ones).


FWIW, I wasn't talking about new features /only/. Working
implementations of pthread and compiler support for synchronized atomics
have been around since long before C++11.

Gerhard
 
Reply With Quote
 
Gerhard Fiedler
Guest
Posts: n/a
 
      06-30-2012
Scott Lurndal wrote:

> Gerhard Fiedler <(E-Mail Removed)> writes:
>>Mark wrote:
>>
>>> On Thu, 28 Jun 2012 15:27:55 -0300, Gerhard Fiedler
>>> <(E-Mail Removed)> wrote:
>>>
>>>>Mark wrote:
>>>>
>>>>> On Wed, 27 Jun 2012 16:12:05 -0500, Paavo Helde
>>>>> <(E-Mail Removed)> wrote:
>>>>>
>>>>>>Mark <(E-Mail Removed)> wrote in
>>>>>>news:t8llu797ibglliasbsqvte9r0fitpmkndk@4ax. com:
>>>>>>
>>>>>>>
>>>>>>>>See e.g. http://en.wikipedia.org/wiki/Volatile_variable
>>>>>>>
>>>>>>> This page does show cases where use of the volatile keyword is
>>>>>>> necessary.
>>>>>>
>>>>>> Not sure what you mean, for C and C++ I see only discussion about
>>>>>> memory- mapped hardware. The examples about multi-thread
>>>>>> synchronization with volatile are talking about Java and C# where
>>>>>> this keyword apparently means something different.
>>>>>
>>>>> As I understand it there is still a risk of the unsafe opimizations
>>>>> which the volatile keyword would prevent.
>>>>
>>>>While that's true, the memory barriers that come with synchronized
>>>>processor instructions, synchronization library functions/objects or the
>>>>new C++ synchronization mechanisms prevent these unsafe optimizations
>>>>also. That's why volatile is not necessary if you use these.
>>>
>>> We can't all rely on new features. I have to maintain code that needs
>>> to work on a large variety of different compilers (including quite old
>>> ones).

>>
>>FWIW, I wasn't talking about new features /only/. Working
>>implementations of pthread and compiler support for synchronized atomics
>>have been around since long before C++11.

>
> And working code using volatile has been around since long before
> pthreads.


So what? It seems to get more and more difficult to make a point that
uses more than two sentences or 12 words...

The line of arguments here is (I'm trying to stay under 12 words):

(A) "volatile" is needed to prevent unsafe compiler optimizations.
(B) Other methods also prevent unsafe optimizations.
(A) I can't use these other methods because I can't use C++11.
(B) Many of those other methods don't need C++11 features.

I couldn't put the whole chain in 12 words, but maybe this shortened
summary helps illustrate anyway why the fact that in some situations
volatile works has nothing to do with this sub-thread.

Gerhard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
how to use volatile key word? 伏虎 C++ 1 07-02-2012 08:31 PM
how to use volatile key word? 伏虎 C Programming 4 06-27-2012 05:28 PM
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key 'Temporary (volatile) Jet DSN for process 0x8fc Thread 0x934 DBC 0x437b94 Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr bazzer ASP .Net 0 03-24-2006 02:22 PM
Use of the Volatile keyword for a pointer to a volatile memory block ben C Programming 5 01-11-2005 05:38 PM



Advertisments