volatile in struct

[Sergei Organov]

Eric Norum <norume at aps.anl.gov> writes:
> On Feb 18, 2004, at 2:50 AM, Sergei Organov wrote:
> 
> > Juergen Zeller <juergen.zeller at argovision.de> writes:
> >> Thank you for all your statements. But this is not the key for my
> >> question. Unfortunately somebody cut out my first mail, so I'm not
> >> wondering something 'other' is discussed. Here my first questiion again:
> >
> > It has been answered already. Here is the initial answer:
> >
> > 1. You should protect your shared data with *the same* primitive in all
> >    the threads. Either use rtems_interrupt_x in both threads or use
> >    rtems_semaphore_x in both threads.
> >
> > 2. Using volatile is almost never a good idea. If you use RTOS primitives
> >    for mutual exclusion correctly, you don't need volatile for your
> >    protected data.
> 
> All-encompassing statements like 'almost a never a good idea' are likely to
> confuse the novice.

I don't think so. What I've stated is just a matter of fact and I believe it
won't confuse anybody more than 'volatile' already does by itself. Besides,
presence of "almost" in the statement would prevent from qualifying it as
"all-encompassing".

> Yes, using volatile variables is probably not a good way to share data among
> tasks.
>
> But volatile is absolutely necessary when working with 'variables' that are
> actually I/O registers.

No, it's not, e.g., one can use assembler to achieve the same result. Please
be careful using all-encompassing statements like this.

In fact I believe OS should provide read_register() and write_register()
primitives (and most OSes do provide them) that ought to be used to access
hardware thus making 'volatile' even less useful.

-- 
Sergei.