this isn't exactly correct. The thread will execute on a single cpu
unless it gets displaced by another thread. Ie if you start 5 threads
on a 4 cpu system, the threads will bounce around rapidly... If you
start 4 threads on a 4 cpu system, daemon (or other process) activity
will cause the same thing to happen. Nothing binds a thread to one cpu
except the process scheduler _trying_ to do this for cache reasons...
Robert Hyatt Computer and Information Sciences
[EMAIL PROTECTED] University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
On Sat, 22 Jan 2000, Juan Gonzalez wrote:
> Rafael,
>
> > That is what I am still not very clear about. What is it meant when
> > "another CPU enters". Is it that while that code segment of outb()'s is
> > being executed, the same segment can be called from some other place? Or
> > does it mean that line 3 gets executed by CPU0, line 3 by CPU1, line 4
> > by CPU0, line 4 by CPU1, etc. All withing the same call to that
> > function?
>
> Once a thread starts executing on a particular processor, it won't jump from one
> processor to the next. The thread will execute completely on one processor until
> the thread terminates (or sleeps), and each instruction gets executed only once.
> What Dave Jones meant was that, in an SMP system, it is possible for 2 different
> threads to call the same function at the same time. When that happens, you get the
> problem of simultaneous access he describes in his article. The problem can be
> avoided with the use of spinlocks.
>
> Hope this helps,
> Juan
>
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
> To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
>
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
