Re: get_current is __pure__, maybe __const__ even

Russell King
2004-09-16T09:04:40Z

On Wed, Sep 15, 2004 at 07:36:04PM -0700, William Lee Irwin III wrote:
> On Wed, Sep 15, 2004 at 07:15:18PM -0400, Jakub Jelinek wrote:
> >>> current will certainly change in schedule (),
>
> On Wed, Sep 15, 2004 at 10:10:20PM -0400, Albert Cahalan wrote:
> > Not really!
>
> Yes it does. The interior of schedule() is C and must be compiled also.
>
>
> At some point in the past, I wrote:
> >> Why would barrier() not suffice?
>
> On Wed, Sep 15, 2004 at 10:10:20PM -0400, Albert Cahalan wrote:
> > I don't think even barrier() is needed.
> > Suppose gcc were to cache the value of
> > current over a schedule. Who cares? It'll
> > be the same after schedule() as it was
> > before.
>
> Not over a call to schedule(). In the midst of schedule().

Actually, I find myself agreeing with Albert here. Consider the
following points:

- "current_thread()" depends on the kernel stack pointer.

- the kernel stack pointer is changed when we switch threads.
- the rest of the register set is changed when we switch threads.

Therefore, if we have current_thread() cached in a register, and we
away from thread A to thread B, and back to A, has the cached copy
become invalid for thread A ? No.

Now look at the same thing from thread B's perspective. Has anything
changed because thread A has run? No.

IOW, think from a tasks point of view. It gets into the scheduler,
and switch_to() is just a normal function which just happens to sleep
for some time.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core