[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38b2ab8a0803240124j61a78649v45533a551f2f7da9@mail.gmail.com>
Date: Mon, 24 Mar 2008 09:24:06 +0100
From: "Francis Moreau" <francis.moro@...il.com>
To: "Chris Snook" <csnook@...hat.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Question about C language.
Hello,
On Sun, Mar 23, 2008 at 8:30 AM, Chris Snook <csnook@...hat.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists