95c0a17b9a
so there's no longer a race there (I used to do the unlock request last, after local completion of all the requests completed, to try to avoid having the passive side reply to the active side, but I don't do that anymore). The unlock side will not "unlock" the window until it actually receives the correct number of results, so we're good there. This fixes an issue where we would receive data on the remote side we weren't expecting that could cause us to release a lock before it really should have been released to the requesting peer. It could also cause a deadlock if one of the processes trying to unlock was "self", as that would result in the active unlock never sending the unlock request, even though it sent the payload, which could cause a counter that should always be positive to hit -1, causing an infinite loop that could only be solved by popping up the stack, which was an impossibility. Refs trac:785 This commit was SVN r13160. The following Trac tickets were found above: Ticket 785 --> https://svn.open-mpi.org/trac/ompi/ticket/785 |
||
|---|---|---|
| .. | ||
| allocator | ||
| bml | ||
| btl | ||
| coll | ||
| common | ||
| io | ||
| mpool | ||
| mtl | ||
| osc | ||
| pml | ||
| rcache | ||
| topo | ||