I didn't realise you were assuming UP, sorry. On SMP there are N values
of `current' and up to N user-mode tasks executing simultaneously.
> A context-switch occurs. Task 2 is guaranteed enough time to complete
> whatever operation it wants to do with shared memory, including
> acquiring a lock, reading and/or writing to it zillions of times
> before the CPU is ever returned to task 1.
A reasonable, though never guaranteed assumption. It particularly tends
to fail under memory pressure if the shared memory is pageable: even
soft faults can take a relatively long time.
> In the kernel, [...] There can be several CPUs attempting
> to modify memory at the same time.
This is the case for user space SMP. Each processor is executing a
different user process, at the same time. So instruction-by-instruction
effects are important. The sharing can be due to explicit shared
memory, or good old threads.
> Given a single CPU, you can often do locking
> (which is against an interrupt because it's the only way you would
> have any problems with a single CPU), by a simple 'cli' instruction.
> However, it is possible to eliminate most such "dead-to-interrupt" code
> by using variables which can be modified atomically as semaphores, to
> protect critical regions of code.
And if the atomicity is extended to SMP-atomicity, i.e. by using the
lock prefix, that same code works on SMP systems too.
-- 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/