>
> Hi Ross -
>
> I'm not exactly sure what you mean. LAM probably calls the system
> function sched_yield in various places (especially if you are using
> the
> shared memory transports). But that shouldn't be causing any problems
> - that code is fairly well tested. It's possible if the shared memory
> RPI is polling a lot (lots of pending communication), that you will
> frequently see sched_yield() in the call stack, as it's where a
> process
> is going to be blocking waiting for something to happen. Could you go
> into a bit more detail about what you are seeing?
>
> By the way, you should either upgrade to LAM 7.1.2b22 or make sure you
> are using the SYSV or TCP rpis (mpirun -ssi rpi sysv) instead of the
> default USYSV rpi. There is a bug in the USYSV rpi on the Apple G5
> multi-cpu machines that can cause data corruption in certain
> situations.
>
>
> Hope this helps,
>
> Brian
Thanks brain
I am sorry i was not clear
I wanted to know where in lam source code is sched_yield defined.
IS it defined in Lam module or is it APPLE(OS) module
Also , the code actually hangs in switch_pri
Can you explain the purpose of sched _yield and switch _pri
Is it have to do with overflow of global process pool on same node
thanks
|
