What I meant is narrowing the global lock to just the accesses to the shared data.  In the current model, the global lock is held more or less for the duration of any MPI call.  Many of these instructions are not on shared data, and can be safely executed concurrently by different threads.  That is, currently the increment and decrement ops are just ++ and -- , because they are within the global lock.  Instead, (2) looks at what it would cost to just grab and release the lock when needed (note that in many cases, we can use special instructions to eliminate the need for the lock entirely).  

Bill

On Jan 31, 2008, at 6:01 PM, Pavan Balaji wrote:

Bill,

Thanks.  Note that in (2), the idea is to not acquire the global lock in the func enter/exit; just as needed for the atomic updates (these aren't the only places that a local atomic op would be needed; the object allocator is another one and that isn't fine-grain ready).  But for the proc-null test, it may be ok.  

How will acquiring a global lock in the increment and releasing it in the decrement be different from the current global lock? These are anyway done at the same time currently for embedded MPI calls. Or did I misunderstand what you meant?

 -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji


William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign