Re: get_current is __pure__, maybe __const__ even

[Russell King]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/