Re: [cdt-dev] EDC and asynchronous operations

["Burton, Felix" <Felix.Burton@xxxxxxxxxxxxx>]

John Cortell wrote:
> Sent: Tuesday, October 12, 2010 12:21 PM
> To: CDT General developers list.; cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] EDC and asynchronous operations
> 
> At 12:34 PM 10/12/2010, Tarassov, Eugene wrote:
> >Hi John,
> >
> > > Interesting idea...using ACPM for client access. But I'm not sure
how
> >practical that would be. Clients using such access would be
unreliable,
> >right? If the cache is invalidated, the client is screwed unless it
has
> >a plan B to use the asynchronous calls. And coding something to try
one
> >way (simple), then another if needed (harder) isn't really a
> >simplification. Then again, perhaps I'm misunderstanding your
> >suggestion. Or perhaps you're thinking of situations where the client
is
> >willing to abort the request altogether if the cache is invalid (even
> >though real-time data could be obtained)
> >
> >If a client encounter an invalid cache item, it can choose:
> >  1. Abort the transaction and return an error.
> >  Or 2. Start data retrieval on the item, add the transaction to the
wait
> >list of the item, re-run the transaction when item state changes.
> >Most clients choose #2.
> 
> Right. All I'm saying is that exposing a cache item to a DSF client
> in an attempt to simplify things for the client is a questionable
> direction, given what I know of ACPM. If you look at the example
> Pawel suggested, the benefit of exposing such an API would be that
> the client can make a synchronous call instead of an
> asynchronous...but it's not really that simple. The client has to
> deal with the fact that the cache may be invalid. That will require
> an asynchronous operation, the avoidance of which was the point of
> adding the cache-based variant. Now, that's not to say ACPM doesn't
> have advantages. I think it could be quite useful for a client that
> needs to get a set of data points, each of which would normally
> require an async operation. But as far as DSF exposing sync variants
> of its services that return cache objects, the benefit is dubious to
> me. Maybe there's something I'm missing.

ACPM does not say that calls are synchronous, it says that calls don't
use a callback mechanism to provide results.  Results are either
returned immediately, if the cache is valid, or an indication that the
cache is invalid is returned so the client can act accordingly.  

The benefits I see from using ACPM are:
1. Data consistency.  Data from multiple sources are guaranteed to be
consistent, even if already validated CIs change while waiting for other
CIs, since we only take data from cache once all CIs are valid.
2. Natural way to issue multiple requests before waiting.  This fills
the pipeline which solves the high latency network issues.
3. Synchronous like programming model.  Since we restart the full
validation we can program in a similar fashion to synchronous program
which is familiar to most programmers and avoids complete rewrite of
existing code.
4. Allows code sharing between Value-add and Agent.

One of the design for TCF is that each service should be small and
simple.  This means that data from multiple services sometimes must be
combined in order to populate a view.  One concrete example is mixed
mode disassembly.  Rather than adding commands to the disassembly
service to combine line number information with disassembly in various
ways, which would make the disassembly service more complex, we prefer
to combine disassembly information with line number information in the
UI since that keeps each service simple and provide maximum flexibility
for the UI, so the UI needs to retrieve information from both sources.
Doing these kind of things using ACPM simplifies the UI code, makes it
more robust and since everything is cached it should be fast.

> > > But, again, it seems useful only when you know up front exactly
what
> >set of data points you need for the transaction.
> >
> >Not sure what you mean. A transaction code decides at run time what
data
> >points to accesses. In fact, this is one of biggest benefits of ACPM:
> >you can write transaction code as traditional sequential code, using
> >'if' and 'for' statements, recursive calls, etc., and access all
cached
> >data as normal variables, without programming call-backs for every
data
> >access. But to be able to do that, you need to wrap into cache items
all
> >your remote data and everything derived from remote data, and various
> >getSomething functions need to return cache item instead of actual
data.
> 
> I understand that. But if you don't know what exactly you will need
> up front, then ACPM is of little use, IMO. E.g., I may know that I
> need A and B, but until I have B I don't know if I'll need C and D.
> And depending on D, I may need E, or F but not both. And if F is some
> particular value, then I need G, H, I, J and K. Such a use case could
> probably not be properly and/or efficiently implemented using ACPM, I
> believe.

IMO, this is an example when using ACPM really is beneficial since you
can write this code in a synchronous like fashion without having to
define callback functions for each piece of data you might need, and
manually create intermediate storage for the pieces of data that you
already have received.

Thanks,
Felix