volatile in struct

[Juergen Zeller]

Sergei Organov schrieb:

>Eric Valette <eric.valette at free.fr> writes:
>  
>
>>Sergei Organov wrote:
>>    
>>
>>>Angelo Fraietta <afraiett at bigpond.net.au> writes:
>>>      
>>>
>>>>>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.
>>>>>          
>>>>>
>>That's true for code modified in different context (e.g especially ISR)
>>    
>>
>>>>I would have to dissagree with that. If I had a loop eg
>>>>
>>>>while (x)
>>>>   {
>>>>      do something
>>>>   }
>>>>
>>>>And x is decremented in another thread, the compiler can optimise x so it
>>>>will never appear changed without volatile
>>>>        
>>>>
>>>Actually your code exactly shows why volatile is evil most of times. The
>>>code
>>>      
>>>
>>>above should be avoided in applications as it is busy-waiting eating
>>>processor time, -- and that was my point, -- as soon as you think you need
>>>'volatile' in your code, think more, -- most probably you are going to
>>>make a mistake. (Sometimes there *is* need for 'volatile', e.g., access to
>>>hardware registers, that's why I've put "almost" in my initial reply). The
>>>above code in an RTOS-friendly application could look like this:
>>>      
>>>
>>>while(1) {
>>>      
>>>
>>>  semaphore_obtain(semaphore);
>>>  do_something;
>>>}
>>>You may substitute semaphore with condition variable or any other
>>>      
>>>
>>>synchronization primitive you like.
>>>
>>>      
>>>
>>Except It doe not work in ISR context. With PCI mapped devices or any memory
>>mapped controller registers, you usually have a loop in the ISR code like :
>>
>>While (Device->IRQ_Status != NO-IRQ_PENDING)
>>	processIrQ ();
>>
>>and YES IRQ status has to be volatile and no you cannot synchrnyse with
>>anything else...
>>    
>>
>
>Did I say volatile is *never* useful?! Citing myself:
>
>  "Using volatile is almost never a good idea."
>
>Do you see "almost"? Another citation:
>
> "Sometimes there *is* need for 'volatile', e.g., access to hardware
> registers"
>
>... and your example is nothing else but hardware register access.
>
>What's your point here?
>
>  
>
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:
 >>>>
I'm using rtems4.6.0 with an i386ex board. I was looking for an error 
for a while and now I figured out that it depends on a volatile 
definition in the following manner:

#if 0
#define VOLATILE /*THIS WORKS for millions of packets without the 
printk-msg 'lost bytes...' */
#else
#define VOLATILE volatile /*here I get the printk-msg 'lost bytes...' 
sometimes (about once per 2000 packets)*/
#endif


typedef struct {

...
unsigned char txbuf[256];
VOLATILE unsigned char txwr; // tx write pointer
VOLATILE unsigned char txrd; // tx read pointer
VOLATILE unsigned char txcount; // tx byte counter
VOLATILE unsigned char txmsgcount; // tx packet counter
...
} MS3_COMDATA;


static rtems_task tx_task (rtems_task_argument arg)
{
...
while (1) {

...
rtems_interrupt_disable (l);
com->txcount -= count;
com->txmsgcount--;
rtems_interrupt_enable (l);
...
}
}


int send (MS3_COMDATA *com, something else )
{
...
rtems_semaphore_obtain (com->sema, RTEMS_NO_TIMEOUT, 0);

/* if the last message was sent there shouldn't remain any bytes in the 
buffer*/
if (!com->txmsgcount && com->txcount) {
printk ("%d lost bytes in txbuffer[%d](%d)\n", com->txcount, port, 
counter[port]);
com->txcount = 0;
}
... /*Code for putting it into txbuf*/

com->txmsgcount++;
rtems_semaphore_release (com->sema);

}


Can anyone out there explain whats going on here? I never thought that 
volatile could be responsible for errors. Is it because it's inside a 
struct?
<<<<

I think I know the meaning of volatile and this is what you discussed.
But how can it be that the use of volatile is more faulty than without?

regards

Juergen