volatile member functions?

volatile member functions?

Post by Thomas Richte » Wed, 30 Jul 2003 06:28:00



Hi folks,

whereas I believe to know what "volatile" means on elementary data types,
what's the meaning of this attribute with respect to member functions?

Specifically, I've the following problem: In a recent project, setjmp/
longjmp has to be used extensively due to the lack of "proper" exception
handling on some architectures we need to support - don't ask, it's really
that messy. Now, gnu c++ warns a lot about possibly clobbered variables
due to setjmp/longjmp, supposedly because these variables could be moved
into registers whose contents is not guaranteed to be restored correctly
after a longjmp back to a previous location. The code looks aproximately
as follows:

class Foo {
        //...
public:
        void bar()
        {
                ...
        }

Quote:};

void DoSomething(...)
{
Foo *f;
        f = ...;
        if (setjmp(...)) {
                f->bar();
        } else {
                f->bar();
        }

Quote:}

Now, as the "f" pointer could be clobbered, I tried to avoid this problem
by declaring "f" as a volatile pointer. However, then g++-3.3 complains
that "Foo::bar" is not a volatile member function.

Could someone please elaborate on what's going on here? I don't quite under-
stand what a volatile member function is supposed to do different than a
regular one, or why I have to declare the member function volatile in first
place as I just want to have a volatile pointer.

Thanks a lot,
        Thomas

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

volatile member functions?

Post by Ulrich Eckhard » Wed, 30 Jul 2003 19:13:24


 > whereas I believe to know what "volatile" means on elementary data types,
 > what's the meaning of this attribute with respect to member functions?

Better than I could exlain it:
http://www.cuj.com/documents/s=7998/cujcexp1902alexandr/

Uli

--
Questions ?
see  C++-FAQ Lite: http://parashift.com/c++-faq-lite/  first !

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

volatile member functions?

Post by Jack Klei » Wed, 30 Jul 2003 19:21:43


On 28 Jul 2003 17:28:00 -0400, Thomas Richter

Quote:> Hi folks,

> whereas I believe to know what "volatile" means on elementary data types,
> what's the meaning of this attribute with respect to member functions?

You may well be mistaken in your belief.  The meaning of volatile in
C++ is problematic right now, although there is an open defect report
about it.

Quote:> Specifically, I've the following problem: In a recent project, setjmp/
> longjmp has to be used extensively due to the lack of "proper" exception
> handling on some architectures we need to support - don't ask, it's really
> that messy. Now, gnu c++ warns a lot about possibly clobbered variables
> due to setjmp/longjmp, supposedly because these variables could be moved
> into registers whose contents is not guaranteed to be restored correctly
> after a longjmp back to a previous location. The code looks aproximately
> as follows:

> class Foo {
>       //...
> public:
>       void bar()
>       {
>               ...
>       }
> };

> void DoSomething(...)
> {
> Foo *f;
>       f = ...;
>       if (setjmp(...)) {
>               f->bar();
>       } else {
>               f->bar();
>       }
> }

> Now, as the "f" pointer could be clobbered, I tried to avoid this problem
> by declaring "f" as a volatile pointer. However, then g++-3.3 complains
> that "Foo::bar" is not a volatile member function.

> Could someone please elaborate on what's going on here? I don't quite under-
> stand what a volatile member function is supposed to do different than a
> regular one, or why I have to declare the member function volatile in first
> place as I just want to have a volatile pointer.

> Thanks a lot,
>       Thomas

The issue is HOW you are trying to use the volatile keyword.

        volatile FOO *f;

....or:

        FOO volatile *f;

....each define an ordinary (non-volatile) pointer to a volatile FOO
object.

Have you tried:

        FOO * volatile f;

....which defines a volatile pointer to a non-volatile FOO?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

volatile member functions?

Post by Jens Kilia » Thu, 31 Jul 2003 07:22:09



> Now, as the "f" pointer could be clobbered, I tried to avoid this problem
> by declaring "f" as a volatile pointer. However, then g++-3.3 complains
> that "Foo::bar" is not a volatile member function.

I suspect that you used

        volatile Foo *f;        // pointer to volatile Foo

when you really wanted

        Foo *volatile f;        // volatile pointer to Foo

Quote:> Could someone please elaborate on what's going on here? I don't quite under-
> stand what a volatile member function is supposed to do different than a
> regular one, or why I have to declare the member function volatile in first
> place as I just want to have a volatile pointer.

The difference is in the type of "this":

        Foo::bar(void)
        {
           // "this" is a pointer to Foo
        }

        Foo::baz(void) volatile
        {
           // "this" is a pointer to volatile Foo
        }

HTH,
        Jens.
--

  http://www.bawue.de/~jjk/          fax:+49-7031-464-7351
                                   As the air to a bird, or the sea to a fish,
                                   so is contempt to the contemptible. [Blake]

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

volatile member functions?

Post by Marco Manfredin » Thu, 31 Jul 2003 08:13:24



> Now, as the "f" pointer could be clobbered, I tried to avoid this
> problem by declaring "f" as a volatile pointer. However, then g++-3.3
> complains that "Foo::bar" is not a volatile member function.

Did you write "volatile Foo *f"? That's wrong. It declares f to be a
pointer to a Foo that is volatile. What you really want is a volatile
pointer to a foo, don't you? (setjmp doesn't clobber the Foo instance,
but the f pointer). Try:

Foo* volatile f;

Now gcc won't complain anymore.

Pointer declarations are easier to understand if they are read
*backwards*. The above gives 'f is a volatile pointer to a Foo', but
this one:

volatile Foo *f;

reads "f is a pointer to a Foo that is volatile"

Suprisingly you can also say:

Foo volatile *f;

And this reads as: 'f is a pointer to a volatile Foo'

Quote:

> Could someone please elaborate on what's going on here?
> I don't quite
> under- stand what a volatile member function is supposed to do
> different than a regular one,

saying "volatile Foo* f" makes the whole Foo and all member data aceess
reachable from f volatile. That means you can only convert f to another
volatile pointer. Calling a method from Foo copies f into the "this"
pointer during the call. This can't work unless the method is declared
volatile which makes the 'this' pointer volatile for member function.

Cheers
Marco

--
The text above is a result of a bug in my newsreader and I take no
responsibility for this text appearing in my post.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

volatile member functions?

Post by llewell » Thu, 31 Jul 2003 17:23:12


 > Hi folks,
 >
 > whereas I believe to know what "volatile" means on elementary data types,
 > what's the meaning of this attribute with respect to member functions?
 >
 > Specifically, I've the following problem: In a recent project, setjmp/
 > longjmp has to be used extensively due to the lack of "proper" exception
 > handling on some architectures we need to support - don't ask, it's really
 > that messy. Now, gnu c++ warns a lot about possibly clobbered variables
 > due to setjmp/longjmp, supposedly because these variables could be moved
 > into registers whose contents is not guaranteed to be restored correctly
 > after a longjmp back to a previous location. The code looks aproximately
 > as follows:
 >
 > class Foo {
 >       //...
 > public:
 >       void bar()

         void bar() volatile

is needed if you want to call this function on volatile
     objects. However, if you just need to use volatile pointers which
     point to non-volatile objects (which seems to be what you want),
     you don't need 'volatile' here.

 >       {
 >               ...
 >       }
 > };
 >
 > void DoSomething(...)
 > {
 > Foo *f;

   volatile Foo * f;

     which delcares that accesses through f will treat the *object
     accessed* (not f) as if it volatile. To understand this, re-write
     as const-on-the-right:

   Foo volatile * f;

     and read it right-to-left: 'f is a pointer to volatile Foo' . Now
     you know f is not a volatile pointer, and is therefor not
     protected from the evils of setjmp/longjmp. The object pointed to
     by f will be accessed as if volatile, but that protects the Foo f
     points at, and not f itself. It also requires you to call only
     volatile members of Foo through f - which apparently you don't
     want.

To make f volatile, and thus protected from setjmp/longjmp, you want:
     'f is a volatile pointer to Foo'. Write this right-to-left, and
     you have:

   Foo * volatile f;

     This protects f from setjmp/longjmp, and there for the compiler
     stops warning you. Note that since the object pointed to by f is
     not volatile, you are not required to make Foo's member functions
     volatile either. (There are people who can make sense of const and
     volatile without the right-to-left trick. I'm not one of them.)

 >       f = ...;
 >       if (setjmp(...)) {
 >               f->bar();
 >       } else {
 >               f->bar();
 >       }
 > }
 >
 > Now, as the "f" pointer could be clobbered, I tried to avoid this problem
 > by declaring "f" as a volatile pointer. However, then g++-3.3 complains
 > that "Foo::bar" is not a volatile member function.

Matchng of volatile qualifiers is akin to matching of const qualifiers
     - that is, you preserve volatile correctness the same way you preserve
     const correctness. (You even use const_cast<> to cast away
     volatile qualifiers...) volatile and const mean different (some
     would say opposite) things to the objects to which they apply, but
     overload resolution, call correctness, and the grammar treat them
     alike. However, the standard library ignores volatile almost
     universally, which means that creatures like:

     volatile vector<int> vv;

     are as far as know useless, and most standard library objects
     cannot be protected from setjmp/longjmp. (For this reason alone,
     if I was to rank the morality of setjmp/longjmp in C++ (not in
     C), I'd rank them about 6 miles below goto. ) You might think hey,
     well, vector<int> 'obviously' doesn't fit in a register, but with
     platforms that add 128 bit registers 8 (SSE, 3dnow) or 32
     (altivec, alpha MVE, etc) at a time, I don't think it's safe to
     say a pair of 32 bit or 64 bit values can't be put in a
     register. (Admittedly, I don't know of any C++ implementations
     which do that *now*, but 32 128 bit registers is a *lot* of
     register space, and someday compilers will start using it.)

 >
 > Could someone please elaborate on what's going on here? I don't quite under-
 > stand what a volatile member function is supposed to do different than a
 > regular one,

Inside a volatile member function, *this will be treated as a volatile
     object. Specificly, if you plan to call setjmp/longjmp from a
     member function, you'd better make it a volatile member
     function. (But that's not what you want here.)

 > or why I have to declare the member function volatile in first
 > place as I just want to have a volatile pointer.
[snip]

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

1. C++, volatile member functions, and threads

After realizing that you could make member functions volatile as
well as const, it occured to me that 'thread-safe' member functions
ought to be marked as volatile, and that objects shared between several
threads ought to be declared as volatile.

        Perhaps the ability to declare member functions volatile is
limited to IBMs C++/Set for OS/2, or g++ 2.7.2.1, but I would guess not.

        My reasoning on this is that if you have a member function that
can be called by multiple threads, it should treat the member variables
as volatile (because multiple threads might be accessing them) until it
obtains a mutex or lock of some sort on the member variables.

        Declaring objects as volatile that are accessed by multiple
threads is a simple extension of declaring variables of basic types to
be volatile when they are accessed by multiple threads.

        This doesn't seem to be current practice.  Is there a good
reason for this that I'm missing, or is it simply an oversight?

Have fun (if at all possible),
--
This space for rent.  Prospective tenants must be short, bright, and
witty.  No pets allowed.  If you wish to live here, or know someone who
does, you may contact me (Eric Hopper) via E-Mail at

    -- Eric Hopper, owner and caretaker.

2. A3000-D Jumper Settings Apollo

3. Volatile member functions

4. US-Contract/Perm. Opportunities

5. volatile -- what does it mean in relation to member functions?

6. Emirates Airbus 330 Takeoff Dubai Airport Pakistan Gold Souk

7. Member Function Pointer to Member Function?

8. CM Tools with Integrated Defect/ProblemTracking

9. casting pointer to member function to pointer to base class member function

10. member functions vs non member functions

11. volatile/non-volatile registry keys...

12. No conversion from volatile Derived to volatile Base?

13. Clarification on volatile variables and function pointers.