CAM-3 March Working Group Minutes
mevenson at hposl21.cup.hp.com
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
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