• Xin Zhao's avatar
    Rewrite code of passive lock control messages. · 0542e304
    Xin Zhao authored
    1. Piggyback LOCK request with first IMMED operation.
    When we see an IMMED operation, we can always piggyback
    LOCK request with that operation to reduce one sync
    message of single LOCK request. When packet header of
    that operation is received on target, we will try to
    acquire the lock and perform that operation. The target
    either piggybacks LOCK_GRANTED message with the response
    packet (if available), or sends a single LOCK_GRANTED
    message back to origin.
    2. Rewrite code of manage lock queue.
    When the lock request cannot be satisfied on target,
    we need to buffer that lock request on target. All we
    need to do is enqueuing the packet header, which contains
    all information we need after lock is granted. When
    the current lock is released, the runtime will goes
    over the lock queue and grant the lock to the next
    available request. After lock is granted, the runtime
    just trigger the packet handler for the second time.
    3. Release lock on target side if piggybacking with UNLOCK.
    If there are active-message operations to be issued,
    we piggyback a UNLOCK flag with the last operation.
    When the target recieves it, it will release the current
    lock and grant the lock to the next process.
    Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>