On Jun 22, 2005, at 2:46 PM, Ross Heikes wrote:
>> 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.
>
> 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
sched_yield is part of the operating system, as is switch_priority.
Both are functions to get the operating system to switch the current
process off the CPU so that someone else can run. LAM will call these
functions when it is waiting for information from it's shared memory
transport.
If your application appears to be hung in one of these functions, look
farther up the call stack - you should see an MPI function in there
somewhere, which is the function call your application made before it
hung. That should at least give you a place to look for the next step.
Hope this helps,
Brian
--
Brian Barrett
LAM/MPI developer and all around nice guy
Have a LAM/MPI day: http://www.lam-mpi.org/
|
