Hi again
Would the lam-mpi development group consider implementing something
similar to what is suggested here,
http://wwwcs.upb.de/cs/plachetk/europvmmpi2002.pdf
It might be any easy way of fixing the thread safety issue with little work?
Thanks
Michael Lees wrote:
> Hi all,
>
> I feel like I'm attempting a some what standard problem and that there
> must be better solutions to what I have so far.
>
>
> I'm attempting to design a system which has an asynchronous MPI
> interface in the form of a 'communication port'. This port interfaces
> with two queues, send and receive. The port should always listen to MPI,
> ie., always have some form of MPI_RECV posted, and place any message
> that comes from MPI into the receive queue of the port. The port should
> also monitor the send queue and make an MPI_SEND command when items are
> placed into the send queue.
>
> Now intuitively I'd have a port with two fairly simple threads, send and
> receive which use condition variables to wake the appropriate threads.
>
> Send Thread
> {
> Wait(sendQinsert)
> get Item from sendQ
> MPI_Send...
> }\\loop
>
>
> Receive Thread
> {
> MPI_RECV...(block until Recv arrives)
> put msg in recv queue
> signal(recvQinsert)
> }\\loop
>
>
> Now this isn't possible with the current lam-mpi as it doesn't support
> MPI_THREAD_MULTIPLE. I'm sure I can't be the only person trying to
> perform asynchronous send and receives to an MPI process? Is there a
> standard method to implementing this kind of design, either by
> collapsing into a single sendANDreceive thread or by applying
> appropriate mutex locks?
>
> Thanks
>
This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
