> This means that the following could happen:
>
> cpu1 memory cpu2
> A=0
> A=1
> * into buffer
> * A=0
> * * cpu2 is a snob
> * * with a short buffer
;)
> * * my test program
> * *uses a rmb()
> * * to trigger that.
> * A=0 <--------
> *
> * cpu1 is lazy
> *
> *
> ------> A=1
>
> As you see, although cpu2 has executed it's instruction after
> cpu1, the value from cpu1 'wins'.
>
> This is the basic problem with _lock_buffer():
> * cpu1 sets current->state and decides that it should sleep
> ++ instructions retire
> * cpu2 notices that is must wake-up the other thread (ie it
> sets current->state)
> ++ instruction retire
> * cpu2 flushes it's write buffer
> * cpu1 flushes it's write buffer
>
> -> lock-up.
Correct.
All acceses to shared data that could be interrupted _must_ be protected by
a locked section.
IMVHO the Intel behaviour is correct due to the fact that if more than one
task write to the same location
without protect it with a lock, it means that 1) the order of writes is
meaningless 2) we know that no more than
one task in a given time access the location.
Cheers,
Davide.
-- "Debian, the Freedom in Freedom."
- 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/