Hello,
I know it's a bit out of topic but this is something I need to clarify for
writing a Linux driver... hope you don't mind.
In my driver I have a global variable that controls a loop such as:
int my_condition;
void change_my_condition(int new)
{
my_condition = new;
}
int foo(void)
{
/* irqs are disabled */
my_condition = 1;
do {
....
local_irq_enable();
cpu_sleep();
local_irq_disable();
} while (my_condition);
}
This variable is modified by an interrupt handler define in another file
by using 'change_my_condition' function.
By reading the ISO C99 specification, I _think_ that I needn't any
kind of barrier
or even use the volatile type qualifier for my_condition variable to make a true
access to 'my_condition' in the controlling expression of the while, but I'm not
sure.
Coud anybody confirm ?
Thanks,
--
Francis
Francis Moreau wrote:
> Hello,
>
> I know it's a bit out of topic but this is something I need to clarify for
> writing a Linux driver... hope you don't mind.
>
> In my driver I have a global variable that controls a loop such as:
>
> int my_condition;
>
> void change_my_condition(int new)
> {
> my_condition = new;
> }
>
> int foo(void)
> {
> /* irqs are disabled */
> my_condition = 1;
> do {
> ....
> local_irq_enable();
> cpu_sleep();
> local_irq_disable();
>
> } while (my_condition);
>
> }
>
> This variable is modified by an interrupt handler define in another file
> by using 'change_my_condition' function.
>
> By reading the ISO C99 specification, I _think_ that I needn't any
> kind of barrier
> or even use the volatile type qualifier for my_condition variable to make a true
> access to 'my_condition' in the controlling expression of the while, but I'm not
> sure.
>
> Coud anybody confirm ?
>
> Thanks,
Even volatile may be insufficient with some architecture/compiler
combinations. You should use explicit barriers wherever you need them,
or Bad Things will happen.
-- Chris
Chris Snook wrote:
> Francis Moreau wrote:
>> Hello,
>>
>> I know it's a bit out of topic but this is something I need to clarify
>> for
>> writing a Linux driver... hope you don't mind.
>>
>> In my driver I have a global variable that controls a loop such as:
>>
>> int my_condition;
>>
>> void change_my_condition(int new)
>> {
>> my_condition = new;
>> }
>>
>> int foo(void)
>> {
>> /* irqs are disabled */
>> my_condition = 1;
>> do {
>> ....
>> local_irq_enable();
>> cpu_sleep();
>> local_irq_disable();
>>
>> } while (my_condition);
>>
>> }
>>
>> This variable is modified by an interrupt handler define in another file
>> by using 'change_my_condition' function.
>>
>> By reading the ISO C99 specification, I _think_ that I needn't any
>> kind of barrier
>> or even use the volatile type qualifier for my_condition variable to
>> make a true
>> access to 'my_condition' in the controlling expression of the while,
>> but I'm not
>> sure.
>>
>> Coud anybody confirm ?
>>
>> Thanks,
>
> Even volatile may be insufficient with some architecture/compiler
> combinations. You should use explicit barriers wherever you need them,
> or Bad Things will happen.
>
> -- Chris
>
Oops, forgot to mention, you should use atomic_t, to avoid aliasing
problems, and ALSO use explicit barriers wherever you need them.
-- Chris
Hello,
On Sun, Mar 23, 2008 at 8:30 AM, Chris Snook <[email protected]> wrote:
> > I know it's a bit out of topic but this is something I need to clarify for
> > writing a Linux driver... hope you don't mind.
> >
> > In my driver I have a global variable that controls a loop such as:
> >
> > int my_condition;
> >
> > void change_my_condition(int new)
> > {
> > my_condition = new;
> > }
> >
> > int foo(void)
> > {
> > /* irqs are disabled */
> > my_condition = 1;
> > do {
> > ....
> > local_irq_enable();
> > cpu_sleep();
> > local_irq_disable();
> >
> > } while (my_condition);
> >
> > }
> >
> > This variable is modified by an interrupt handler define in another file
> > by using 'change_my_condition' function.
> >
> > By reading the ISO C99 specification, I _think_ that I needn't any
> > kind of barrier
> > or even use the volatile type qualifier for my_condition variable to make a true
> > access to 'my_condition' in the controlling expression of the while, but I'm not
> > sure.
> >
> > Coud anybody confirm ?
> >
> > Thanks,
>
> Even volatile may be insufficient with some architecture/compiler
> combinations. You should use explicit barriers wherever you need them,
> or Bad Things will happen.
>
Really ?
Could you give me some details please ?
As I said previously, I don't think I need any barriers here because this code
doesn't have any reordering issues and futhermore only one CPU will be up
at this time.
Actually the only issue I can see is about compiler aliases. I don't know if
in that case it could use an alias for 'my_condition'. Looking at the code, it
would be a bad idea but I can't find anything about this in the C specification.
The C spec talks about sequence points but I'm really confused when reading
that part...
Thanks
--
Francis
On Sun, Mar 23, 2008 at 8:32 AM, Chris Snook <[email protected]> wrote:
> Oops, forgot to mention, you should use atomic_t, to avoid aliasing
> problems, and ALSO use explicit barriers wherever you need them.
>
Interesting, could you give me some pointers about aliasing please ?
Thanks
--
Francis