Some non-RAC version of the script to find lock waiter and its blocker may not work in RAC. For 
instance, if you depend on v$lock.block to be 1 as a blocker, you'll be surprised to see that all 
sessions almost always have a value of 2 for the block column. In RAC, this value 2 means not more 
than that the session is not waiting to get a lock; it could be blocking others or not blocking, 
but it's not requesting. If it were requesting or waiting for a lock, block would be 0. So in RAC, 
the correct way to identify blocking and waiting session is to follow the script in Note:398519.1, 
which is

select * from gv$lock where (ID1,ID2,TYPE) in (select ID1,ID2,TYPE from gv$lock where request>0);

In 10g, gv$session has BLOCKING_INSTANCE and BLOCKING_SESSION. Querying these columns may take a 
while to run, at least up to Oracle 10.2.0.3 (I can't find the bug#). It's not using CPU though. 
But a potential incorrect value problem should stop you from using this method. See Bug 5677058 
and 5481650. I think somewhere I read these problems are fixed in 10.2.0.4.