volatility and extern "C" functions

[Jacek Dziedzic]

Hello!

In my program I have a matrix class that can be simplified to

class Matrix {
public:
// ... plenty of methods
void diagonalize_via_LAPACK();

private:
double *internal_storage; // matrix's internal representation
// ... other fields

};

The memory at internal_storage is new'ed. The method
diagonalize_via_LAPACK calls an extern "C" function from
a third-party library (LAPACK).

This extern "C" function linked from somewhere else
DOES modify memory pointed by internal_storage. Do I need
to declare the pointer as

volatile double *internal_storage;

to prevent the compiler from making assumptions about the
contents of memory pointed by internal_storage?

I realize it would be wise to do so if it was, for
instance, modified asynchronously by a timer thread or
something completely unbeknown to the compiler. But is
it also the case with an extern "C" function, or does
the compiler "realize" that since I'm passing the pointer
as "double*" and not "const double*", the memory pointed
by it can be modified? I'm using a heavily-optimizing
compiler, so I'd rather be 100% sure!


thanks in advance,
- J.

 

[Wiseguy]

This extern "C" function linked from somewhere else

DOES modify memory pointed by internal_storage. Do I need
to declare the pointer as

volatile double *internal_storage;

to prevent the compiler from making assumptions about the
contents of memory pointed by internal_storage?

I'm not completely sure but I don't think it would hurt to do so.
I'm leaning in favor of saying "yes".

 

[gpriv]

As long as your "C" routine is running on the same thread you don't
need to use volatile.

 

[Jacek Dziedzic]

I'm not completely sure but I don't think it would hurt to do so.
I'm leaning in favor of saying "yes".

But I need to know if it *should indeed* be there.
It also turns out that this is a performance-critical part
of my program. I haven't done any tests to see if adding
"volatile" slows things down, but I'd be reluctant to add
it only "because it wouldn't hurt".

especially since

(e-mail address removed) wrote

As long as your "C" routine is running on the same thread
you don't need to use volatile.

it IS running on the same thread, or so I think (my program
is not multithreaded).

So, can anyone else give a decisive vote?

tia,
- J.

 

[Jack Klein]

Hello!

In my program I have a matrix class that can be simplified to

class Matrix {
public:
// ... plenty of methods
void diagonalize_via_LAPACK();

private:
double *internal_storage; // matrix's internal representation
// ... other fields

};

The memory at internal_storage is new'ed. The method
diagonalize_via_LAPACK calls an extern "C" function from
a third-party library (LAPACK).

This extern "C" function linked from somewhere else
DOES modify memory pointed by internal_storage. Do I need
to declare the pointer as

volatile double *internal_storage;

to prevent the compiler from making assumptions about the
contents of memory pointed by internal_storage?

I realize it would be wise to do so if it was, for
instance, modified asynchronously by a timer thread or
something completely unbeknown to the compiler. But is
it also the case with an extern "C" function, or does
the compiler "realize" that since I'm passing the pointer
as "double*" and not "const double*", the memory pointed
by it can be modified? I'm using a heavily-optimizing
compiler, so I'd rather be 100% sure!


thanks in advance,
- J.

If you call a function and:

1. It accepts a pointer to non-const

2. You pass it a pointer to non constant data

....then it makes no difference if the function has C linkage or not.
The compiler must assume that the function might modify the data.

Volatile is not necessary here. Depending on how you access elements
of the array in your C++ code, it could significantly slow things
down. Especially considering that volatile is broken for fundamental
types in C++ already.

 

[Jacek Dziedzic]

If you call a function and:

1. It accepts a pointer to non-const

2. You pass it a pointer to non constant data

...then it makes no difference if the function has C linkage or not.
The compiler must assume that the function might modify the data.

Volatile is not necessary here. Depending on how you access elements
of the array in your C++ code, it could significantly slow things
down.

Thank you very much. That's basically what I wanted to hear!

Especially considering that volatile is broken for fundamental
types in C++ already.

Could you eleaborate on this? I've never heard that volatile
was "broken"?

thanks,
- J.