[ofa-general] [PATCH] Lock _do_madrpc for thread safety

[Sasha Khapyorsky]

Hi Ira,

On 13:26 Fri 10 Jul     , Ira Weiny wrote:
> > 
> > Have you read Sasha's commit 51d25384626a7b4ba386c414ed56c647a7bf64df
> > from 12/26/08 ? In it, he states " I think that it will be more robust
> > for multithreaded
> > application to use its own synchronization methods (pthread mutex or any
> > other) for better control. "
> 
> I missed that.  Thanks.

Yes. And also I guess this will break WinOF.

> However, I am starting to lean towards putting something in libibmad.  The
> problem for me is that in the ibnetdisc library I can't control what the
> application is doing.  And more importantly I can't allow the application to
> do anything (at least at certain times).

You don't need to use madrpc in ibnetdisc library then. madrpc stuff is
just simple interface for tools like smpquery. Make something smarter
using umad_send/recv().

> I have been thinking about this since I sent the last email and I have another
> idea.  What if we made ibmad queue all responses it gets in _do_madrpc which
> are not the response it is looking for.

You can add such sort of API, but I think that it should be new (higher)
API layer.

> Applications, or parts of applications, which want to do parallel queries
> would still have to match up their own responses to queries but they would not
> have to worry about losing messages in the ibmad layer.

madrpc() is too primitive interface for such applications. There would
be better to use umad_send/recv() directly or may be mad_send_via().
Example is mcast_storm.c distributed with ibsim.

Sasha