CAM-3 March Working Group Minutes

Mark Evenson mevenson at
Sat Apr 1 18:13:14 PST 1995

One other comment.

> > > >>                   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.

This is only true if you can block whenever you're entering a driver.
Most OS's have contexts where you can't block in which drivers have to
exectue at times.  That's what I had in mind when I said that immediate
CCBs are "essentially precluded with implicit synchronization".  Thanks
for fleshing out the reasoning behind this.

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

And to achieve OS independence in light of differing blocking models.

> ...



More information about the T10 mailing list