On Apr 19, 2007, at 1:45 PM, pooja_at_[hidden] wrote:
> I want to put semaphore in bml.h--- mca_bml_send before and after
> SO that when a process call btl_send it first lock a global
> variable X and
> then proceeds.Also if an external Tcp function wants to send data it
> should first lock global variable X and then proceed.
> Can anyone tell me only changing bml.h is enough or are there any
> files where I need to make changes.
This is likely to be a complex issue because there's the put and get
functions as well. ob1 uses a fairly complex algorithm to decide
when to call the bml interface functions -- I doubt that the use of a
semaphore in a single location is going to do what you want.
(why a semaphore, anyway -- why not a mutex?)
> (As I tried doing this and run mpi program it gave me ORTE time out
> also when I changed file back to normal it was not compiling and
> giving me
> error in libmca_bml.la etc...unfortunately I deleted entire folder and
> downloaded new version.)
Changing bml.h should have zero effect on the ORTE layer. ORTE is a
whole different abstraction and wholly below the OMPI layer. There
are a few places in the OMPI layer that interact with the lower ORTE
later, but the bml is not one of them.
I'm guessing that you had some other problem.
If you're going to be working continually with Open MPI, you might
want to get a subversion checkout.
> Can any one please help me and tell me how should I go about
> locks/semaphore in bml layer so that all mpi process access lock
> (of same
> priority ) and continue working while Tcp acquire only when network is
> free(or there is lot of serial operation between 2 mpi sends).
I want to emphasize again that this won't give you what you have
described in previous mails: the PML interface is designed to be
asynchronous. So when you call send/put/get, it only (possibly)
*starts* the communication transfer. When you unlock upon return,
you're allowing the alternate communication mechanism to come in and
start another communication method (via a different BTL, perhaps),
but it does not change that there may still be activity occurring
down in the kernel and/or hardware. Also, this scheme does not
account for received message contention -- it only [tries to] account
for sending contention.
So even if you get the locking working the way that you want, I don't
think that you're going to get the overlap and multiplexing that you