C / C++ / MFC

6-Nov-13 3:32

Hi, I read an old program, the programmer wrote some function like the following block, I am wonder if the volatile is necessary with a local variable.

As I know, local variable is in stack, every time enter the function, local variable get a new stack address.

C++

void logRealClock(void)
{
   volatile int second;
   volatile int minute;
   volatile int hour;
   
   second = globalDate->second;
   minute = globalDate->minute;
   hour = globalDate->hour; 
   ....
   checkTime(second,minute,hour);
   ...
   globalRTC_REG.second = second;
   globalRTC_REG.minute = minute;
   globalRTC_REG.hour = hour;   

}

David Knechtges6-Nov-13 3:37

David Knechtges

6-Nov-13 3:37

The volatile keyword is used to force the compiler to not assume the variable's value. This is so that it does not optimize accesses away.

http://en.wikipedia.org/wiki/Volatile_variable[^]

econy6-Nov-13 4:19

6-Nov-13 4:19

Thanks,I read the Wiki article, but I still can't see the need of volatile for local variable.

The example code only cause size of generated assembly code bigger, but useless.

C++

int main() {
    volatile int a = 10, b = 100, c = 0, d = 0;
 
    printf("%d", a + b);
 
    a = b;
    c = b;
    d = b;
 
    printf("%d", c + d);
 
    return 0;
}

pasztorpisti6-Nov-13 4:23

6-Nov-13 4:23

If you pass a pointer to your variable outside the function (for example to an interrupt handler) and then you guarantee the lifetime of that variable (for example by blocking on an event with this thread) and you want to use the variable in the function after finishing the block operation on the event then it could be useful (because the value of the variable might have been changed by other threads) but what I've described previously sounds quite pervert and awfully designed code. I don't think volatile local vars to be useful.

econy6-Nov-13 4:44

6-Nov-13 4:44

thanks, what you said like:

C++

volatile int* aPtr = aSharedMem;

right? then in another thread,

C++

aSharedMem = aNewValue;

then in the current thread, stalled before aSharedMem=aNewValue, then resume, *aPtr get the aNewValue.

if local variable just copy a global's value, like:
volatile int aLocal = aGlobal;
then in another thread, aGlobal = aNewValue;
in current thread, stalled before aGlobal = aNewValue, then resume, aLocal will get aNewValue?

pasztorpisti6-Nov-13 5:15

6-Nov-13 5:15

C++

// global scope. some other threads may use this pointer after its initialization...
int* globalptr;

void myfunc()
{
    volatile int localvar = 0;
    globalptr = &localvar;
    //blah blah
    //wait for something
    
    // start using the volatile var again:
    printf("localvar: %d\n", localvar);
    // In this case the compiler is forced to read up the value of
    // localvar again from memory even if it would be present in a register.
    // Maybe the compiler is smart enough to figure out that forming a pointer
    // to the local var is suspicious but even if you hide this from the compiler
    // with some ugly magic it will read the value from the memory when it comes
    // to printing/using it without doing any optimizations/caching.
}

econy6-Nov-13 5:36

6-Nov-13 5:36

is the following scenario, the volatile is useful?

C++

//global scope
int globalVar;

//in task1
void task1SetGlobal(void)
{
  
  if (xyz == 100) 
     globalPtr = 100;
}

...
//in task2
void task2GetGlobal(void)
{
  volatile int localVar = 0;

  localVar = globalVar;

  if (localVar < 100 ) doSth;
  else if (localVar == 100) do100Thing;

}

pasztorpisti6-Nov-13 5:39

6-Nov-13 5:39

Not really. In order to understand volatile you should first understand some other concepts like multithreading and caching and all the related problems that can cause problems along with the optimizations done by the compiler.

Aescleal6-Nov-13 4:49

Aescleal

6-Nov-13 4:49

It's not necessarily bad design to pass a reference to a local variable to another thread for processing. One example of where it might come in handy is splitting up an array into chunks and processing each chunk in separate threads. However using volatile as a synchronisation mechanism is not the sort of thing I'd recommend to try and avoid a proper synchronisation mechanism (i.e. a condition variable).

pasztorpisti6-Nov-13 5:09

6-Nov-13 5:09

Then we agree, in this case some kind of memory fence is used for synchronization that is usually built into the synch primitives like events. In this case you usually make a function call too to pass the job to another thread and usually this already prevents a compiler from optimizing away some things.

_com_error not caught by 'Try-Catch' code

jschell6-Nov-13 8:03

jschell

6-Nov-13 8:03

Probably just me but given the code that was posted I can't see any reason for volatile.

Mike Grove5-Nov-13 22:14

Mike Grove

5-Nov-13 22:14

I have added some code (to an existing MFC/ATL application), to communicate with a piece of hardware that comes complete with com-based driver software.

(Before I forget: I'm writing C++ in Visual Studio 2010, for Windows7).

My code is based closely upon the sample code that the hardware manufacturer supplied, and is as follows;

C++

#import "GlobMgr.dll"	no_namespace // I/O funtionality
#import "IviDriverTypeLib.dll"	no_namespace // IVI inherent functionality
#import "agu265x.dll"	no_namespace // Instrument specific functionality

IAgilentU265xPtr spAgDrvrSlot1;

CCMDS::CCMDS( ...class details not relevant... )
  : CUSBDevice( ...ditto... )
{
  // Must first call either CoInitialize or CoInitializeEx to initialize COM **DON'T NEED THIS BIT - COM ALREADY INITIALISED**
  //HRESULT hr = S_OK;
  //hr = CoInitialize( NULL );
  //if ( hr != S_OK )
  //{
  //	if ( hr == S_FALSE )
  //	{
  //		AfxMessageBox( "Com Already Initialised" );
  //	}
  //	else
  //	{
  //		AfxMessageBox( "Co-initialise Failed" );
  //	}
  //}

  // Create and Initialise instances of the Agilent driver for
  // each of the four U2635A I/O modules in the U2781A rack
  spAgDrvrSlot1.CreateInstance( __uuidof( AgilentU265x ) );

  try
  {
	spAgDrvrSlot1->Initialize( "USBInstrument1", VARIANT_FALSE, VARIANT_TRUE, "" );
  }
  catch ( _com_error e )
  {
	AfxMessageBox( "Driver Initialise Failed" );
  }

HOWEVER, my code crashes at the Initialize(USBInstrument1...) statement with a Windows dialog saying

Quote:
First-chance exception at 0x755bb9bc in IOHandler.exe: Microsoft C++ exception: _com_error at memory location 0x001de4e0..

Why this code fails at all is a mystery but the big question is why does Windows crash with a dialog rather than my Try-Catch code catching the error in the controlled fashion I'd hoped for??

Richard MacCutchan5-Nov-13 22:26

Richard MacCutchan

5-Nov-13 22:26

Presumably something in Windows is catching the error and not re-throwing it. You may wish to talk to the people who provided this code for more help.

Veni, vidi, abiit domum

Mike Grove5-Nov-13 22:53

Mike Grove

5-Nov-13 22:53

Ok, got it thanks - Windows was catching the error and not re-throwing it because... I'm running in Debug and had Visual Studio set to catch all Exceptions Blush | :O

Aescleal5-Nov-13 22:36

Aescleal

5-Nov-13 22:36

Something you might have missed: You can set the VC++ debugger up to catch exceptions where they're thrown and it generates a message like the dialogue you're getting. Are you running under the debugger with that setting enabled?

If you're not running under a debugger then it's something else but I thought I'd try and clear that up first!

Mike Grove5-Nov-13 22:57

Mike Grove

5-Nov-13 22:57

Ooops, sorry - I missed your reply earlier! Yes, you were correct - thank-you Thumbs Up | :thumbsup:

Feeling like a newbie (again) Frown | :(