Jeff Squyres wrote:
> Although this doesn't help you in the immediate future, let me drop a
> rather unsubtle hint and say that support for MPI_THREAD_MULTIPLE is
> probably only a few months away.
>
> Stay tuned to this list for more details...
A few months, wow!
I had read somewhere that you didn't plan to be thread safe in version
7.x, or does that mean you'll be at 8.x in a few months?
I have in the current implementation a polling system as you describe, I
collapse the two threads into one and post a non-blocking recv, I then
loop performing buffered sends while the recv isn't complete.
I was looking into other comercial MPI versions but I think the polling
system will suffice for a few months, hopefully I can just change the
communication system when the new version arrives.
Great news
Thanks for you help
-Mike
>
>
> On Thu, 10 Jun 2004, Michael Lees wrote:
>
>> 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.
>>
>> _______________________________________________
>> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>>
>
--
Mike
mhl_at_[hidden]
http://www.cs.nott.ac.uk/~mhl/
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.
|
