Re: Delayed Xaction and LOCK#

[rwalter@auspex.com (Richard Walter)]

> >
> > There is possibility of deadlock, the way specification for delayed xaction
> > for exclusive accesses has been specified (PCI2.1 PP 52).  It says that
> > target needs to compare (latched) LOCK# signal to find if request is being
> > repeated.  On the other hand there is no requirement for initiator (PCI 2.1
> > PP 76) that it must retry an exclusive access as exculsive access only.
> 
> I don't see how you came to that conclusion.  On page 51, the last
> paragraph of 3.3.3.3.2 does say "The master must repeat the transaction
> exactly as the original request...".  That should include LOCK# as well.  I
> don't think there is anything on page 76 that contradicts that.  (Yes, you
> are required to release LOCK# if the transaction is retried, but when you
> attempt it again, you'd have to assert LOCK#.)

I agree, the master must come back with LOCK# asserted because otherwise that
wouldn't be identical to the original request.

> BTW, I don't think it is possible to do locked transactions as delayed
> transactions.  So, matching LOCK# merely makes it so that a locked
> transaction doesn't get serviced with a completion from a previous delayed
> transaction to the same address, which might have come from a different
> agent.  Is it important to protect against that case?  May be not.  The
> spec writers apparently thought otherwise.

Sure it's possible to do locked tranactions as delayed transactions.  The
first sentence of section 3.3.3.3.5. (pg. 52) reads "A locked transaction can
be completed using delayed transaction termination."  The essential difference
between a delayed transaction response and a normal retry response is that
the target which is doing the delayed transaction considers itself locked even
though the master doesn't think that he got the lock.  And the target (which
now is locked) cannot enqueue any more transactions until the delayed
transaction does complete.

> 
> > Any comments ?
> >
> > Thanks,
> > Tripathi.
> 
> Monish Shah
> Hewlett Packard

-Richard Walter
rwalter@auspex.com
Note: I speak for myself, not for Auspex.
‡
(