Thread: About volatile type qualifier

  1. #1
    Registered User
    Join Date
    Sep 2011
    Location
    Athens , Greece
    Posts
    357

    About volatile type qualifier

    If I have a pointer variable indicating memory location in which we have stored what user entered and the pointer is of type volatile if the user gives the character 'a' twice , then this character will not be fetched twice from the memory but only when the character is changed???

    This is the one meaning of the volatile? the other is that the value will be changed without the program itself change it? thank you

  2. #2
    Registered User
    Join Date
    Sep 2007
    Posts
    1,012
    I'm not sure what you're asking in the first paragraph.

    All volatile does, essentially, is tell the compiler that whenever a volatile-qualified object it used, shortcuts (i.e. optimizations) may not be taken, and the object must be accessed just as the source code says.

    Examples:
    Code:
    volatile int i;
    
    i = 0;
    if(i == 0) { ...}
    Normally, a compiler would be allowed to skip the test, because it “knows” that the test is true. But since it's volatile, the compiler's not allowed to assume that, and must load i again.

    Code:
    volatile int i;
    
    i = 0;
    i = 0;
    Here the compiler would normally be allowed to omit one of these assignments, because it's redundant. However, with volatile, it must perform both.

    This is generally useful when you've got a pointer to something like a memory mapped I/O device; the compiler can't know what it will return, even if it thinks it does.

    Or you might use volatile if you're trying to scrub sensitive data from memory and you're afraid the compiler will think that the writes are redundant.

    The standard mandates one use of volatile: signal handlers are not allowed to write to global objects (i.e. those with static storage duration) unless those objects are of type “volatile sig_atomic_t”.

  3. #3
    Registered User
    Join Date
    Sep 2011
    Location
    Athens , Greece
    Posts
    357
    Οκ. But I am not sure that I have understood the usefulness of volatile keyword. I was confused because I had read the following about the volatile from a book:

    [I] To see why volatile is needed , suppose that a pointer p points to a memory location that contains the most recent character typed at the user's keyboard. This location is volatile: its value changes each time the user enters a character. We might use the following loop to obtain characters from the keyboard and store them in a buffer array :

    Code:
     
    
    while( buffer not full) {
    wait for input;
    buffer[i] = *p;
    if ( buffer[i++] == '\n' )
    break;
    }
    A sophisticated compiler might notice that this loop changes neither *p nor p. So it could optimize the program by altering it so that *p is fetched just once :

    Code:
    store *p in a register 
    while(buffer not full) {
    wait for input;
    buffer = value stored in register;
    if (buffer[i++] = '\n')
    break;
    }
    
    


    The optimized program will fill the buffer with many copies of the same character not exactly what we have in mind.Declaring tha p points to volatile data avoids this problem by telling the compiler that *p must be fetched from memory every time it is needed.


    I can't understand the last lines. What is the problem we avoid? and how your explanation about volatile can solve it. If you want to fetch only the different characters and not the same for example enter twice the character 'a' how you can achieve this according to volatile's theory you said that load even the redudant assignments.

    "fetching" I think is when you get something from the memory I am right?
    Last edited by Mr.Lnx; 06-26-2014 at 04:46 PM.

  4. #4
    Registered User
    Join Date
    Sep 2007
    Posts
    1,012
    To fetch something is to get it from memory, yes.

    The hypothetical keyboard issue is this:

    You have a pointer to some special location in memory; let's say address 0x100. If you were to look at the byte at address 0x100 (i.e., if you were to fetch it), it would be whatever the user just typed on his keyboard. You can see that whatever value is at location 0x100 is completely dependent on what the user just typed.

    Now, as far as C is concerned, there is nothing else happening on the computer. It has no idea about this special 0x100 location. C thinks that the only way the value at address 0x100 can change is if it changes it. Basically, it's a safe to which only C has the combination. Because of this, it can avoid reading the value by remembering what it last placed there. If you tell C to store the value 0 at 0x100, it now "knows" that, until it stores a new value, 0x100 always contains the value 0. Therefore, it doesn't have to waste time loading that value each time you want it. Instead, it just remembers that it stored 0.

    Alternatively, if C itself never stores a value there, it has to read it; but once it's read the value, it again "knows" that it won't change, since it believes nothing else is running on the system. So once it's read the value at 0x100, it remembers that value and never reads 0x100 again.

    Problem: behind C's back, the keyboard is placing different values at location 0x100. Now C's assumption is wrong. The keyboard stores 'A', for example, and C reads that 'A' from 0x100. But now it knows that 0x100 has the value 'A', and unless C stores a new value, it can just keep returning 'A', because nothing else will be writing to 0x100. So you try to read 10 characters from 0x100 and they all come back as 'A', because C never bothered to check if it changed.

    Solution: tell it that 0x100 is volatile, which means that now C knows something else might be changing the values. It's not allowed to "remember" the last value it read or stored; it has to check each time. Now when it reads 10 characters from 0x100, they're whatever the keyboard placed there, even if C doesn't think that the value changed.

  5. #5
    Registered User
    Join Date
    Sep 2011
    Location
    Athens , Greece
    Posts
    357
    Ok I get the point thank you very much it is very good explanation

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. volatile Qualifier on Function
    By User Name: in forum C Programming
    Replies: 13
    Last Post: 06-05-2013, 11:52 AM
  2. Const qualifier
    By karthik537 in forum C Programming
    Replies: 3
    Last Post: 02-17-2011, 12:24 AM
  3. ROM Qualifier (Part 2)
    By Syndacate in forum C Programming
    Replies: 7
    Last Post: 02-06-2011, 04:21 PM
  4. Discards qualifier from pointer target type?
    By pdstatha in forum C Programming
    Replies: 1
    Last Post: 04-16-2002, 02:12 PM
  5. Type Qualifier const
    By PutoAmo in forum C Programming
    Replies: 3
    Last Post: 03-30-2002, 08:55 PM