CAM-3 March Working Group Minutes

kdg at summit.novell.com kdg at summit.novell.com
Fri Mar 31 07:59:00 PST 1995


> > >>                   The CAM Status information for immediate 
> > >> CCBs shall be obtain on return from the service call by examining 
> > >> the CAM Status field.
> > 
> > >Same as previous comment, plus is essentially precluded with implicit
> > >synchronization.
> > 
> > I'm still don't understand.
> 
> With implicit synchronization you can't have immediate CCBs because
> when the xpt_action call returns (assuming you've added implicit 
> synchronization semantics onto it) it won't necessarily have been
> seen by the SIM and acted on yet (because it's queued in a 
> sychronization queue).

Actually the specific issue here is related to a non-blocking process model,
which is part of CDDE's implicit synchronization strategy, not to implicit
synchronization in general.  Implicit synchronization could be achieved by
transparently acquiring a blocking mutex (sleep lock) on all entries to a
driver.

The non-blocking model requires that calling threads are not tied up waiting
for resources, events, or synchronization on behalf of the driver.  Such a
model requires asynchronous callbacks for any request which might wait.

CDDE uses a non-blocking model to achieve lighter-weight, higher-concurrency
implicit synchronization than the single mutex technique can achieve.

"Immediate CCBs" as Mark appears to be interpreting them (I haven't read the
relevant CAM-3 materials) would require the called routine to spin or block
waiting for event completion, which would violate the non-blocking rules.

On the other hand, if Immediate CCBs corresponded to a class of requests which
could be guaranteed to never need to wait for resources, h/w events, state changes,
or synchronization, then they would work even in a non-blocking environment.

Probably the trickiest of these requirements is synchronization.  Since CCBs
are at the boundary between two drivers, there will probably always be the
potential to need to wait for driver serialization (if the called driver instance
is already busy).

- Kurt.Gollhardt at summit.novell.com




More information about the T10 mailing list