Re: spinlock

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Wed, 1 Dec 1999 15:43:20 +0100


David Wragg wrote:
> It isn't defined in those terms though: I don't have a copy of the old
> or new standard to hand from which to quote chapter and verse, but
> both say that the implementation must strictly follow the rules of the
> abstract machine with respect to a volatile object.
>
> This implies that it must do all reads and writes. But it implies more
> than that.

For example on UP x86 boxes, an increment is atomic always. But on SMP
boxes, it is not atomic w.r.t. other processes sharing the memory unless
the code includes the "lock" prefix. This is irrelevant to the C
standard of course, but shows that you must decide what abstract machine
to use...

> > In the case of GCC's extended asm, that means it is ok to read a
> > volatile, pass the effective address of the /copy/ as the asm operand,
> > then write the modified copy back to the volatile.
>
> In the abstract machine, there are no copies of objects.

There are temporaries used for evaluation. If I write `x += 1', afaik
that may be expressed by the compiler as `tmp = x; x = tmp + 1'.

> Of course, inline asm is not covered by the standard, and so gcc
> cannot be required to respect volatile for inline asm in the name of
> standards comformance. But the cases where you might want to use
> inline asm are likely to be cases where, if you use volatile, you want
> the compiler to strictly observe it. So for it to ignore volatile for
> inline asm would be stupid enough that I would feel justified in
> calling it a bug.

I have seen GCC developers discussing the meaning of volatile, with
someone complaining that `x++' (where `x' is volatile) was not always
using a single instruction. I recall that while it is desirable to use
single instructions, it is not required.

> I ought to say that this is purely my opinion, and I have no idea what
> the position of the gcc developers is on this matter. There are people
> around who know far more about gcc than me, so if my reasoning is
> flawed, hopefully they will enlighten us.

That would be nice.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/