Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23089 > unrolled thread

Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually

Back to article view | Back to comp.lang.c

Contents

  Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Myth__Buster <raghavanil4m@gmail.com> - 2012-07-05 10:44 -0700
    Re: Clarification on the applicability of compile-time optimization to a  struct variable which encompasses a mixture of fields declared as volatile  and non-volatile individually pete <pfiland@mindspring.com> - 2012-07-05 14:59 -0400
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Myth__Buster <raghavanil4m@gmail.com> - 2012-07-07 12:53 -0700
    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-05 23:22 +0100
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 13:08 -0400
        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 09:20 +1200
          Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 14:01 -0400
            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 18:11 -0400
              Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 14:33 -0400
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 11:29 +1200
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 16:27 -0400
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 12:37 +1200
                      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 17:29 -0400
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 15:50 +1200
                          Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 19:55 -0400
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-07 17:04 +0300
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 00:10 -0700
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Gareth Owen <gwowen@gmail.com> - 2012-07-07 10:00 +0100
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 10:55 -0700
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-07 15:13 -0700
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 04:40 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-07 17:20 +0300
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 10:33 -0700
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 08:16 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 05:12 -0400
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 09:24 -0400
                      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 06:07 -0400
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Keith Thompson <kst-u@mib.org> - 2012-07-07 13:26 -0700
                          Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 16:04 -0400
                            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually James Kuyper <jameskuyper@verizon.net> - 2012-07-09 11:14 -0400
            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 16:58 -0700
              Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 17:20 -0400
                Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 19:39 -0700
                  Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 18:54 -0400
                    Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 20:12 -0700
                      Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 19:25 -0400
                        Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 20:33 -0700
                          Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 19:47 -0400
              Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Jens Gustedt <jens.gustedt@loria.fr> - 2012-07-07 15:47 +0200
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 06:58 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Philip Lantz <prl@canterey.us> - 2012-07-14 21:46 -0700
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-07 16:19 -0700
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Jens Gustedt <jens.gustedt@loria.fr> - 2012-07-08 09:40 +0200
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually James Kuyper <jameskuyper@verizon.net> - 2012-07-08 10:51 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Philip Lantz <prl@canterey.us> - 2012-07-13 23:25 -0700
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-14 14:37 -0700
                      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-14 14:46 -0700
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Philip Lantz <prl@canterey.us> - 2012-07-14 21:39 -0700
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 17:24 -0700
        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-07 02:33 +0100
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Myth__Buster <raghavanil4m@gmail.com> - 2012-07-07 12:53 -0700

Page 1 of 3  [1] 2 3  Next page →

#23089 — Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually

#include <stdio.h>

struct InterruptData
{
        int numberOfInterrupts;
        volatile int timer;
        int numberOfTimesInterruptsMasked;
} InterruptMonitor;


/*
 *  Interrupt handler code.
 */
 
int main(void)
{
    InterruptMonitor = InterruptMonitor;      
    
    printf("\n LOG - InterruptMonitor.numberOfInterrupts : %d \n",
                      InterruptMonitor.numberOfInterrupts);
                
    printf("\n LOG - InterruptMonitor.timer : %d \n",
                     InterruptMonitor.timer);
                     
    printf("\n LOG - InterruptMonitor.numberOfTimesInterruptsMasked : %d \n",
                     InterruptMonitor.numberOfTimesInterruptsMasked);

    return 0;
}

-------------

InterruptMonitor = InterruptMonitor; - Should this be a candidate for compile-time optimization in spite of having a field qualified as volatile?

Cheers,
Raghavan Santhanam

[toc] | [next] | [standalone]

#23090 — Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually

Myth__Buster wrote:
> 
> #include <stdio.h>
> 
> struct InterruptData
> {
>         int numberOfInterrupts;
>         volatile int timer;
>         int numberOfTimesInterruptsMasked;
> } InterruptMonitor;
> 
> /*
>  *  Interrupt handler code.
>  */
> 
> int main(void)
> {
>     InterruptMonitor = InterruptMonitor;

> InterruptMonitor = InterruptMonitor; 
> - Should this be a candidate for compile-time optimization
> in spite of having a field qualified as volatile?

I don't think so.

Merely accessing a volatile object,
is considered to be a side effect.


-- 
pete

[toc] | [prev] | [next] | [standalone]

#23186

On Thursday, July 5, 2012 11:59:49 AM UTC-7, pete wrote:
> Myth__Buster wrote:
> > 
> > #include <stdio.h>
> > 
> > struct InterruptData
> > {
> >         int numberOfInterrupts;
> >         volatile int timer;
> >         int numberOfTimesInterruptsMasked;
> > } InterruptMonitor;
> > 
> > /*
> >  *  Interrupt handler code.
> >  */
> > 
> > int main(void)
> > {
> >     InterruptMonitor = InterruptMonitor;
> 
> > InterruptMonitor = InterruptMonitor; 
> > - Should this be a candidate for compile-time optimization
> > in spite of having a field qualified as volatile?
> 
> I don't think so.
> 
> Merely accessing a volatile object,
> is considered to be a side effect.
> 
> 
> -- 
> pete

Okay, thanks for the clarification.

Cheers,
Raghavan Santhanam

[toc] | [prev] | [next] | [standalone]

#23098

Myth__Buster <raghavanil4m@gmail.com> writes:

> #include <stdio.h>
>
> struct InterruptData
> {
>         int numberOfInterrupts;
>         volatile int timer;
>         int numberOfTimesInterruptsMasked;
> } InterruptMonitor;
>
>
> /*
>  *  Interrupt handler code.
>  */
>  
> int main(void)
> {
>     InterruptMonitor = InterruptMonitor;      
<snip>
>     return 0;
> }
>
> -------------
>
> InterruptMonitor = InterruptMonitor; - Should this be a candidate for
> compile-time optimization in spite of having a field qualified as
> volatile?

I fear that your example may be one "a bit like" the code you really
care about, but I have to talk about what you post...

To a very large extent, the C standard washes it hands of volatile
objects.  Sure, it says a fair bit about what *may* happen but it also
says "[w]hat constitutes an access to an object that has volatile-
qualified type is implementation-defined" (6.7.3 p7) and "[a]n actual
implementation need not evaluate part of an expression if it can deduce
that [...] no needed side effects are produced (including any caused by
[...] accessing a volatile object)" (5.1.2.3 p4).

Together, these give an implementation so much leeway that you often
need to refer to the implementation, not the standard.  For example, an
implementation may well be able to deduce that the assignment is not a
"needed side effect", coming as it does at the start of main.  Equally,
an implementation may treat all accesses to volatile-qualified objects
with kid gloves.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23110

On Thu, Jul 05, 2012 at 11:22:49PM +0100, Ben Bacarisse wrote:
> Myth__Buster <raghavanil4m@gmail.com> writes:
> 
> > #include <stdio.h>
> >
> > struct InterruptData
> > {
> >         int numberOfInterrupts;
> >         volatile int timer;
> >         int numberOfTimesInterruptsMasked;
> > } InterruptMonitor;
> >
> >
> > /*
> >  *  Interrupt handler code.
> >  */
> >  
> > int main(void)
> > {
> >     InterruptMonitor = InterruptMonitor;      
> <snip>
> >     return 0;
> > }
> >
> > -------------
> >
> > InterruptMonitor = InterruptMonitor; - Should this be a candidate for
> > compile-time optimization in spite of having a field qualified as
> > volatile?
> 
> I fear that your example may be one "a bit like" the code you really
> care about, but I have to talk about what you post...
> 
> To a very large extent, the C standard washes it hands of volatile
> objects.  Sure, it says a fair bit about what *may* happen but it also
> says "[w]hat constitutes an access to an object that has volatile-
> qualified type is implementation-defined" (6.7.3 p7) and "[a]n actual
> implementation need not evaluate part of an expression if it can deduce
> that [...] no needed side effects are produced (including any caused by
> [...] accessing a volatile object)" (5.1.2.3 p4).
> 
> Together, these give an implementation so much leeway that you often
> need to refer to the implementation, not the standard.  For example, an
> implementation may well be able to deduce that the assignment is not a
> "needed side effect", coming as it does at the start of main.  Equally,
> an implementation may treat all accesses to volatile-qualified objects
> with kid gloves.

This is a concern in my mind right now as I'm writing some posix
threads code, and so obviously there are a large number of variables
which ought to be declared volatile.  I don't have a copy of the
standard, so I was wondering whether the volatile attribute is
inherited by structures contained within a structure declared
volatile.  Example:


struct substruct {
	int a, b;
};

struct container {
	int	n_coord;
	struct substruct coord[];
};


volatile struct container c;

The question is, does c.coord[i].a have the volatile attribute?



Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#23111

On 07/ 7/12 05:08 AM, Uncle Steve wrote:
> On Thu, Jul 05, 2012 at 11:22:49PM +0100, Ben Bacarisse wrote:
>>
>> To a very large extent, the C standard washes it hands of volatile
>> objects.  Sure, it says a fair bit about what *may* happen but it also
>> says "[w]hat constitutes an access to an object that has volatile-
>> qualified type is implementation-defined" (6.7.3 p7) and "[a]n actual
>> implementation need not evaluate part of an expression if it can deduce
>> that [...] no needed side effects are produced (including any caused by
>> [...] accessing a volatile object)" (5.1.2.3 p4).
>>
>> Together, these give an implementation so much leeway that you often
>> need to refer to the implementation, not the standard.  For example, an
>> implementation may well be able to deduce that the assignment is not a
>> "needed side effect", coming as it does at the start of main.  Equally,
>> an implementation may treat all accesses to volatile-qualified objects
>> with kid gloves.
>
> This is a concern in my mind right now as I'm writing some posix
> threads code, and so obviously there are a large number of variables
> which ought to be declared volatile.

What leads you to that conclusion?  That line of though usually implies 
you are misunderstanding the relationship between volatile and threads.

What are you trying to achieve with volatile?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#23112

On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
> On 07/ 7/12 05:08 AM, Uncle Steve wrote:
> >On Thu, Jul 05, 2012 at 11:22:49PM +0100, Ben Bacarisse wrote:
> >>
> >>To a very large extent, the C standard washes it hands of volatile
> >>objects.  Sure, it says a fair bit about what *may* happen but it also
> >>says "[w]hat constitutes an access to an object that has volatile-
> >>qualified type is implementation-defined" (6.7.3 p7) and "[a]n actual
> >>implementation need not evaluate part of an expression if it can deduce
> >>that [...] no needed side effects are produced (including any caused by
> >>[...] accessing a volatile object)" (5.1.2.3 p4).
> >>
> >>Together, these give an implementation so much leeway that you often
> >>need to refer to the implementation, not the standard.  For example, an
> >>implementation may well be able to deduce that the assignment is not a
> >>"needed side effect", coming as it does at the start of main.  Equally,
> >>an implementation may treat all accesses to volatile-qualified objects
> >>with kid gloves.
> >
> >This is a concern in my mind right now as I'm writing some posix
> >threads code, and so obviously there are a large number of variables
> >which ought to be declared volatile.
> 
> What leads you to that conclusion?  That line of though usually implies 
> you are misunderstanding the relationship between volatile and threads.
> 
> What are you trying to achieve with volatile?

Well, I have some data structures that will be accessed from arbitrary
threads, so I want to make sure there's no funny business happening
behind the scenes where the compiler decides that certain accesses are
optional.

Here's a little snippet of code which shows the issue, albeit without
nested structures:


#include <local_time.h>


struct sample_s {
   T64   a, b;
};

typedef struct sample_s sample;

#define SAMPLES   100



#define nsclock(p) { \
   volatile struct timespec T; \
   clock_gettime(CLOCK_MONOTONIC, &T); \
   p = T.tv_sec * 1000000000 + T.tv_nsec; \
}

void  do_timing(sample * p)
{
   volatile T64   s, e, v;
//   volatile unsigned int i;

   nsclock(s);
   nsclock(s);
   
//   for(i = 0; i < 1 ; i++);
   nsclock(e);

   p->a = (e - s);

   nsclock(e);

   p->b = (e - s);
   
   return;
}


void  emit_sample(sample *p)
{
   fprintf(stdout, "%-5d %-5d %-5d\n", p->a, p->b, p->b - p->a);

   return;
}




int   main(char *argv, int argc)
{
   sample tr[SAMPLES + 1];
   int i;

   tr[SAMPLES].a = tr[SAMPLES].b = 0;
   

   for(i = 0; i < SAMPLES; i++)
      do_timing(&tr[i]);

   fprintf(stdout, "Timing results for %d samples:\n\n", SAMPLES);

   fprintf(stdout, "%-5s %-5s %-5s\n", "A", "B", "B - A");
   
   for(i = 0; i < SAMPLES; i++)
      emit_sample(&tr[i]);

   exit(0);
}

 
So, without including all the crap in local_time.h, I have to explain
a few definitions.

T64 is an unsigned long long int representing microseconds since
epoch, but I ended up using it as if it represented nanoseconds since
epoch since my i3 dual core laptop has a nanosecond-resolution timer.

The variable declared volatile are required otherwise some variable
accesses are optimized out, giving inaccurate results during the data
acquisition phase.  The problems here are magnified when these access
patterns occur with competing threads.  IIRC, mutexes are not memory
access barriers and solve different problems.


Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#23113

On 7/6/2012 2:01 PM, Uncle Steve wrote:
> On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
>> On 07/ 7/12 05:08 AM, Uncle Steve wrote:
>>>[...]
>>> This is a concern in my mind right now as I'm writing some posix
>>> threads code, and so obviously there are a large number of variables
>>> which ought to be declared volatile.
>>
>> What leads you to that conclusion?  That line of though usually implies
>> you are misunderstanding the relationship between volatile and threads.
>>
>> What are you trying to achieve with volatile?
>
> Well, I have some data structures that will be accessed from arbitrary
> threads, so I want to make sure there's no funny business happening
> behind the scenes where the compiler decides that certain accesses are
> optional.

     Although the latest "C11" Standard adds some multi-threading
support, I'll ignore that because (1) C11 implementations are not
exactly thick upon the ground as yet, (2) you mentioned you're
using Pthreads anyhow, and (3) I haven't studied the C11 threading
stuff closely enough to be a competent commentator. ;-)

     So: As long as you're using an established non-C-specific
threading framework, I suggest you visit comp.programming.threads,
a newsgroup devoted to multi-threading issues.  There you will learn
that `volatile' is neither necessary *nor* sufficient in connection
with variables shared between threads.  (You needn't take my word on
this: Just browse the comp.programming.threads archives and you'll
see the local experts refuting this misunderstanding every couple
weeks. It's comp.programming.threads' equivalent of `void main'.)

     Or, as my first threading teacher put it, "Don't Do That."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#23114

On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
> On 7/6/2012 2:01 PM, Uncle Steve wrote:
> >On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
> >>On 07/ 7/12 05:08 AM, Uncle Steve wrote:
> >>>[...]
> >>>This is a concern in my mind right now as I'm writing some posix
> >>>threads code, and so obviously there are a large number of variables
> >>>which ought to be declared volatile.
> >>
> >>What leads you to that conclusion?  That line of though usually implies
> >>you are misunderstanding the relationship between volatile and threads.
> >>
> >>What are you trying to achieve with volatile?
> >
> >Well, I have some data structures that will be accessed from arbitrary
> >threads, so I want to make sure there's no funny business happening
> >behind the scenes where the compiler decides that certain accesses are
> >optional.
> 
>     Although the latest "C11" Standard adds some multi-threading
> support, I'll ignore that because (1) C11 implementations are not
> exactly thick upon the ground as yet, (2) you mentioned you're
> using Pthreads anyhow, and (3) I haven't studied the C11 threading
> stuff closely enough to be a competent commentator. ;-)
> 
>     So: As long as you're using an established non-C-specific
> threading framework, I suggest you visit comp.programming.threads,
> a newsgroup devoted to multi-threading issues.  There you will learn
> that `volatile' is neither necessary *nor* sufficient in connection
> with variables shared between threads.  (You needn't take my word on
> this: Just browse the comp.programming.threads archives and you'll
> see the local experts refuting this misunderstanding every couple
> weeks. It's comp.programming.threads' equivalent of `void main'.)
> 
>     Or, as my first threading teacher put it, "Don't Do That."

Is there are C standard threading framework?

Threaded code is a de-facto reality in today's multi-core environment.
Save for the embedded sector, most systems will run threads in
parallel, and that is that.  C has to recognize this watershed moment
in the refinement of the language.

While the specifics of an implementation within a given operating
system are not C issues, certain common optimizations can be a problem
with certain algorithms, and so there ought to be a C solution to the
problem.  What is it about the volatile attribute that makes it 
insufficient in your mind to the problem presented by threaded code?


Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#23118

On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
>> On 7/6/2012 2:01 PM, Uncle Steve wrote:
>>> On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
>>>> On 07/ 7/12 05:08 AM, Uncle Steve wrote:
>>>>> [...]
>>>>> This is a concern in my mind right now as I'm writing some posix
>>>>> threads code, and so obviously there are a large number of variables
>>>>> which ought to be declared volatile.
>>>>
>>>> What leads you to that conclusion?  That line of though usually implies
>>>> you are misunderstanding the relationship between volatile and threads.
>>>>
>>>> What are you trying to achieve with volatile?
>>>
>>> Well, I have some data structures that will be accessed from arbitrary
>>> threads, so I want to make sure there's no funny business happening
>>> behind the scenes where the compiler decides that certain accesses are
>>> optional.
>>
>>      Although the latest "C11" Standard adds some multi-threading
>> support, I'll ignore that because (1) C11 implementations are not
>> exactly thick upon the ground as yet, (2) you mentioned you're
>> using Pthreads anyhow, and (3) I haven't studied the C11 threading
>> stuff closely enough to be a competent commentator. ;-)
>>
>>      So: As long as you're using an established non-C-specific
>> threading framework, I suggest you visit comp.programming.threads,
>> a newsgroup devoted to multi-threading issues.  There you will learn
>> that `volatile' is neither necessary *nor* sufficient in connection
>> with variables shared between threads.  (You needn't take my word on
>> this: Just browse the comp.programming.threads archives and you'll
>> see the local experts refuting this misunderstanding every couple
>> weeks. It's comp.programming.threads' equivalent of `void main'.)
>>
>>      Or, as my first threading teacher put it, "Don't Do That."
>
> Is there are C standard threading framework?

Yes, read C11.  If you are familiar with pthreads, you'll see where most 
of the new primitives originate.

> Threaded code is a de-facto reality in today's multi-core environment.
> Save for the embedded sector, most systems will run threads in
> parallel, and that is that.

Only if you incorporate threads in your code either explicitly or 
implicitly with something like OpenMP.

> C has to recognize this watershed moment
> in the refinement of the language.

It has.

> While the specifics of an implementation within a given operating
> system are not C issues, certain common optimizations can be a problem
> with certain algorithms, and so there ought to be a C solution to the
> problem.  What is it about the volatile attribute that makes it
> insufficient in your mind to the problem presented by threaded code?

Given you are the one going against conventional wisdom, what in your 
mind makes volatile a solution to the problem presented by threaded code?

In addition, what is "the problem presented by threaded code"?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#23123

On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
> On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> >On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
> >>On 7/6/2012 2:01 PM, Uncle Steve wrote:
> >>>On Sat, Jul 07, 2012 at 09:20:57AM +1200, Ian Collins wrote:
> >>>>On 07/ 7/12 05:08 AM, Uncle Steve wrote:
> >>>>>[...]
> >>>>>This is a concern in my mind right now as I'm writing some posix
> >>>>>threads code, and so obviously there are a large number of variables
> >>>>>which ought to be declared volatile.
> >>>>o
> >>>>What leads you to that conclusion?  That line of though usually implies
> >>>>you are misunderstanding the relationship between volatile and threads.
> >>>>
> >>>>What are you trying to achieve with volatile?
> >>>
> >>>Well, I have some data structures that will be accessed from arbitrary
> >>>threads, so I want to make sure there's no funny business happening
> >>>behind the scenes where the compiler decides that certain accesses are
> >>>optional.
> >>
> >>     Although the latest "C11" Standard adds some multi-threading
> >>support, I'll ignore that because (1) C11 implementations are not
> >>exactly thick upon the ground as yet, (2) you mentioned you're
> >>using Pthreads anyhow, and (3) I haven't studied the C11 threading
> >>stuff closely enough to be a competent commentator. ;-)
> >>
> >>     So: As long as you're using an established non-C-specific
> >>threading framework, I suggest you visit comp.programming.threads,
> >>a newsgroup devoted to multi-threading issues.  There you will learn
> >>that `volatile' is neither necessary *nor* sufficient in connection
> >>with variables shared between threads.  (You needn't take my word on
> >>this: Just browse the comp.programming.threads archives and you'll
> >>see the local experts refuting this misunderstanding every couple
> >>weeks. It's comp.programming.threads' equivalent of `void main'.)
> >>
> >>     Or, as my first threading teacher put it, "Don't Do That."
> >
> >Is there are C standard threading framework?
> 
> Yes, read C11.  If you are familiar with pthreads, you'll see where most 
> of the new primitives originate.

Well, I don't follow gcc development, so I don't know when those
features will be available on my system.

> >Threaded code is a de-facto reality in today's multi-core environment.
> >Save for the embedded sector, most systems will run threads in
> >parallel, and that is that.
> 
> Only if you incorporate threads in your code either explicitly or 
> implicitly with something like OpenMP.

Well, sure, but I'd like to think that multithreaded applications will
be popular.  It helps to improve the interactivity of applications
with a GUI frontend for one thing, never mind what you can do with
message-passing interfaces or asynchronus network I/O threads.
 
> >C has to recognize this watershed moment
> >in the refinement of the language.
> 
> It has.

O.K., so do nested structure elements inherit the parent structure's
volatile attribute?
 
> >While the specifics of an implementation within a given operating
> >system are not C issues, certain common optimizations can be a problem
> >with certain algorithms, and so there ought to be a C solution to the
> >problem.  What is it about the volatile attribute that makes it
> >insufficient in your mind to the problem presented by threaded code?
> 
> Given you are the one going against conventional wisdom, what in your 
> mind makes volatile a solution to the problem presented by threaded code?
>
> In addition, what is "the problem presented by threaded code"?

Well, code optimization from global CSE might eliminate memory
accesses to variable that could be modified by other threads in ways
that affect the algorithm.  Depends of the code.


Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#23124

On 07/ 7/12 08:27 AM, Uncle Steve wrote:
> On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
>> On 07/ 7/12 06:33 AM, Uncle Steve wrote:
>>>
>>> Is there are C standard threading framework?
>>
>> Yes, read C11.  If you are familiar with pthreads, you'll see where most
>> of the new primitives originate.
>
> Well, I don't follow gcc development, so I don't know when those
> features will be available on my system.

Then use your platform's native threading primitives.

>>> Threaded code is a de-facto reality in today's multi-core environment.
>>> Save for the embedded sector, most systems will run threads in
>>> parallel, and that is that.
>>
>> Only if you incorporate threads in your code either explicitly or
>> implicitly with something like OpenMP.
>
> Well, sure, but I'd like to think that multithreaded applications will
> be popular.  It helps to improve the interactivity of applications
> with a GUI frontend for one thing, never mind what you can do with
> message-passing interfaces or asynchronus network I/O threads.

There already are.

>>> C has to recognize this watershed moment
>>> in the refinement of the language.
>>
>> It has.
>
> O.K., so do nested structure elements inherit the parent structure's
> volatile attribute?

A volatile T is a volatile T no matter what it contains.

>>> While the specifics of an implementation within a given operating
>>> system are not C issues, certain common optimizations can be a problem
>>> with certain algorithms, and so there ought to be a C solution to the
>>> problem.  What is it about the volatile attribute that makes it
>>> insufficient in your mind to the problem presented by threaded code?
>>
>> Given you are the one going against conventional wisdom, what in your
>> mind makes volatile a solution to the problem presented by threaded code?
>>
>> In addition, what is "the problem presented by threaded code"?
>
> Well, code optimization from global CSE might eliminate memory
> accesses to variable that could be modified by other threads in ways
> that affect the algorithm.  Depends of the code.

If the code depends on volatile, it is broken.  Use the atomics or 
synchronisation primitives provided by the language or platform.  They 
exist for a reason.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#23130

On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> On 07/ 7/12 08:27 AM, Uncle Steve wrote:
> >On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
> >>On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> >>>
> >>>Is there are C standard threading framework?
> >>
> >>Yes, read C11.  If you are familiar with pthreads, you'll see where most
> >>of the new primitives originate.
> >
> >Well, I don't follow gcc development, so I don't know when those
> >features will be available on my system.
> 
> Then use your platform's native threading primitives.

Doing so would incur a performance penalty in comparison to my
synchronization primitives in some circumstances.

> >>>Threaded code is a de-facto reality in today's multi-core environment.
> >>>Save for the embedded sector, most systems will run threads in
> >>>parallelo, and that is that.
> >>
> >>Only if you incorporate threads in your code either explicitly or
> >>implicitly with something like OpenMP.
> >
> >Well, sure, but I'd like to think that multithreaded applications will
> >be popular.  It helps to improve the interactivity of applications
> >with a GUI frontend for one thing, never mind what you can do with
> >message-passing interfaces or asynchronus network I/O threads.
> 
> There already are.

Yes.  There are many examples of such code.
 
> >>>C has to recognize this watershed moment
> >>>in the refinement of the language.
> >>
> >>It has.
> >
> >O.K., so do nested structure elements inherit the parent structure's
> >volatile attribute?
> 
> A volatile T is a volatile T no matter what it contains.

Look.  In threaded applications, the truth associated with the value
associated with certain variables can be somewhat indeterminate.  If
that's true in your code, you might want to be aware of it.
 
> >>>While the specifics of an implementation within a given operating
> >>>system are not C issues, certain common optimizations can be a problem
> >>>with certain algorithms, and so there ought to be a C solution to the
> >>>problem.  What is it about the volatile attribute that makes it
> >>>insufficient in your mind to the problem presented by threaded code?
> >>
> >>Given you are the one going against conventional wisdom, what in your
> >>mind makes volatile a solution to the problem presented by threaded code?
> >>
> >>In addition, what is "the problem presented by threaded code"?
> >
> >Well, code optimization from global CSE might eliminate memory
> >accesses to variable that could be modified by other threads in ways
> >that affect the algorithm.  Depends of the code.
> 
> If the code depends on volatile, it is broken.  Use the atomics or 
> synchronisation primitives provided by the language or platform.  They 
> exist for a reason.

You aren't listening to me.



Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#23138

On 07/ 7/12 09:29 AM, Uncle Steve wrote:
> On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
>> On 07/ 7/12 08:27 AM, Uncle Steve wrote:
>>> On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
>>>> On 07/ 7/12 06:33 AM, Uncle Steve wrote:
>>>>>
>>>>> Is there are C standard threading framework?
>>>>
>>>> Yes, read C11.  If you are familiar with pthreads, you'll see where most
>>>> of the new primitives originate.
>>>
>>> Well, I don't follow gcc development, so I don't know when those
>>> features will be available on my system.
>>
>> Then use your platform's native threading primitives.
>
> Doing so would incur a performance penalty in comparison to my
> synchronization primitives in some circumstances.

In other words, correctness would incur a performance penalty in 
comparison to your synchronization primitives in some circumstances.

>>> O.K., so do nested structure elements inherit the parent structure's
>>> volatile attribute?
>>
>> A volatile T is a volatile T no matter what it contains.
>
> Look.  In threaded applications, the truth associated with the value
> associated with certain variables can be somewhat indeterminate.  If
> that's true in your code, you might want to be aware of it.

If I could parse that, I'd respond to it.

>>>>> While the specifics of an implementation within a given operating
>>>>> system are not C issues, certain common optimizations can be a problem
>>>>> with certain algorithms, and so there ought to be a C solution to the
>>>>> problem.  What is it about the volatile attribute that makes it
>>>>> insufficient in your mind to the problem presented by threaded code?
>>>>
>>>> Given you are the one going against conventional wisdom, what in your
>>>> mind makes volatile a solution to the problem presented by threaded code?
>>>>
>>>> In addition, what is "the problem presented by threaded code"?
>>>
>>> Well, code optimization from global CSE might eliminate memory
>>> accesses to variable that could be modified by other threads in ways
>>> that affect the algorithm.  Depends of the code.
>>
>> If the code depends on volatile, it is broken.  Use the atomics or
>> synchronisation primitives provided by the language or platform.  They
>> exist for a reason.
>
> You aren't listening to me.

You aren't making much sense.

An example of you your synchronization primitives would clear things up.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#23139

On Sat, Jul 07, 2012 at 03:50:59PM +1200, Ian Collins wrote:
> On 07/ 7/12 09:29 AM, Uncle Steve wrote:
> >On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> >>On 07/ 7/12 08:27 AM, Uncle Steve wrote:
> >>>On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
> >>>>On 07/ 7/12 06:33 AM, Uncle Steve wrote:
> >>>>>
> >>>>>Is there are C standard threading framework?
> >>>>
> >>>>Yes, read C11.  If you are familiar with pthreads, you'll see where most
> >>>>of the new primitives originate.
> >>>
> >>>Well, I don't follow gcc development, so I don't know when those
> >>>features will be available on my system.
> >>
> >>Then use your platform's native threading primitives.
> >
> >Doing so would incur a performance penalty in comparison to my
> >synchronization primitives in some circumstances.
> 
> In other words, correctness would incur a performance penalty in 
> comparison to your synchronization primitives in some circumstances.

You probably shouldn't be using google translate to massage my code
into something you can understand.  It doesn't work like that.
 
> >>>O.K., so do nested structure elements inherit the parent structure's
> >>>volatile attribute?
> >>
> >>A volatile T is a volatile T no matter what it contains.
> >
> >Look.  In threaded applications, the truth associated with the value
> >associated with certain variables can be somewhat indeterminate.  If
> >that's true in your code, you might want to be aware of it.
> 
> If I could parse that, I'd respond to it.

Yeah well it happens.
 
> >>>>>While the specifics of an implementation within a given operating
> >>>>>system are not C issues, certain common optimizations can be a problem
> >>>>>with certain algorithms, and so there ought to be a C solution to the
> >>>>>problem.  What is it about the volatile attribute that makes it
> >>>>>insufficient in your mind to the problem presented by threaded code?
> >>>>
> >>>>Given you are the one going against conventional wisdom, what in your
> >>>>mind makes volatile a solution to the problem presented by threaded 
> >>>>code?
> >>>>
> >>>>In addition, what is "the problem presented by threaded code"?
> >>>
> >>>Well, code optimization from global CSE might eliminate memory
> >>>accesses to variable that could be modified by other threads in ways
> >>>that affect the algorithm.  Depends of the code.
> >>
> >>If the code depends on volatile, it is broken.  Use the atomics or
> >>synchronisation primitives provided by the language or platform.  They
> >>exist for a reason.
> >
> >You aren't listening to me.
> 
> You aren't making much sense.
> 
> An example of you your synchronization primitives would clear things up.

Sorry, you're going to have to wait.


Regards,

Uncle Steve

-- 
The moon has never been closer.

[toc] | [prev] | [next] | [standalone]

#23155

Uncle Steve <stevet810@gmail.com> writes:
> On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> > If the code depends on volatile, it is broken.  Use the atomics or 
> > synchronisation primitives provided by the language or platform.  They 
> > exist for a reason.
> 
> You aren't listening to me.

PKB.

I think you'll find that it's not Ian who needs the assistance.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

[toc] | [prev] | [next] | [standalone]

#23140

Uncle Steve <stevet810@gmail.com> writes:

> What is it about the volatile attribute that makes it
> insufficient in your mind to the problem presented by
> threaded code?

Let's take a specific example:

    volatile int a = 1, b = 2;

    ... start up threads X and Y ...

    ... in parallel ... {

        ... in thread X ... {
            a = 3;
            b = 4;    
        }

        ... in thread Y ... {
            printf( "a = %d\n", a );
            printf( "b = %d\n", b );
        }
    
    }

Question: what values for a and b might thread Y print?

Answer:  Besides the obvious possibilities of {1,2}, {3,2},
and {3,4}, the Standard allows a conforming implementation
to define volatile access in such a way that thread Y might
print 1 for a but 4 for b.  In other words, using volatile
is not enough to guarantee write ordering.  Moreover that
lack of guarantee holds true even if write-barrier opcodes
are used before and after each volatile-qualified access.

So it's kind of unfortunate but true - the meaning of volatile
is inherently non-portable.  You may be able to write code
using volatile to do inter-thread communication that works
reliably on a number of implementations, but that depends
on decisions made by those implementations, and not just on
the Standard.


> I don't have a copy of the standard, [...]

Easily solved.  For C99:

   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

For C11:

   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

[toc] | [prev] | [next] | [standalone]

#23143

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Question: what values for a and b might thread Y print?
>
> Answer:  Besides the obvious possibilities of {1,2}, {3,2},
> and {3,4}, the Standard allows a conforming implementation
> to define volatile access in such a way that thread Y might
> print 1 for a but 4 for b.  

Would it be correct to say that if both a & b are volatile, then the
compiler may not reorder them, but the processor may (in the absence of
an explicit memory barrier)?

In which case, volatile may be (non-portably) sufficient for i386
uni-processors, say.

[toc] | [prev] | [next] | [standalone]

#23173

Gareth Owen <gwowen@gmail.com> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Question: what values for a and b might thread Y print?
>>
>> Answer:  Besides the obvious possibilities of {1,2}, {3,2},
>> and {3,4}, the Standard allows a conforming implementation
>> to define volatile access in such a way that thread Y might
>> print 1 for a but 4 for b.  
>
> Would it be correct to say that if both a & b are volatile, then the
> compiler may not reorder them, but the processor may (in the absence of
> an explicit memory barrier)?

It's more complicated than that.  Certainly a write-buffer may
change the order of the writes (as one example), but it's also
true that "memory access" as far as a particular implementation is
concerned might not be the same as native machine instructions.
For a typical implementation, it's probably true that there will
be native machine instructions for every volatile access, and in
the same order as the abstract semantics would imply, but the
Standard allows enough latitude that implementations don't have to
do that (if they don't want to).

> In which case, volatile may be (non-portably) sufficient for i386
> uni-processors, say.

Again, it's likely that this will be true for most such
implementations, but the Standard doesn't force it to be
true if an implementation is determined to behave otherwise
(please excuse the anthropomorphism).

[toc] | [prev] | [next] | [standalone]

#23191

On Jul 7, 2:00 am, Gareth Owen <gwo...@gmail.com> wrote:
> Would it be correct to say that if both a & b are volatile, then the
> compiler may not reorder them, but the processor may (in the absence of
> an explicit memory barrier)?
>
> In which case, volatile may be (non-portably) sufficient for i386
> uni-processors, say.

Perhaps. You'd have to check the hardware docs for the i386 and the
compiler docs to see how it treats volatile. I know some parts of my
company do exactly hacks like this. They wrote some message passing
software which has some of the highest throughput rates of any message
passing software in existence, and they did it by using volatile,
using specific guarantees of the x86, using specific implicit or
explicit guarantees of the compiler, and using some inline assembly. I
actually had the opportunity to hear a technical presentation by them
for my team, and I specifically asked what they do for other
platforms. The answer is that they only support the x86 architecture
(give or take - I'm not the expert), and that's apparently not a
problem as their customers are "fine" with that.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web