Re: [PATCH 2/3] skip_prolgoue (amd64)

[Yao Qi <yao at codesourcery dot com>]

On 12/05/2013 08:00 PM, Pedro Alves wrote:
> I think we can.  My view here is that handling an event
> is a quick and short lived operation.  GDB bursts a few reads
> in sequence, and then moves on to the next event.  In that
> scenario, you get as much stale results with or without a cache.

I disagree.  Results may be staled with cache, but results may be 
different, not staled, without cache.  They are different because they 
are red on different times, but all of them are valid.  It is a snapshot 
of a piece of memory on a certain moment.

> IOW, even without the cache, running threads can change memory as
> GDB reads it, and so the chances of hitting stale data with or
> without a cache are practically the same.  OTOH, distinct target
> events (and commands, etc.) can trigger quite apart (time-wise),
> and that break the odd balance -- not flushing the cache
> between events increases the changes of hitting stale data,

I suspect you meant "chances" instead of "changes".

> compared to not having a cache.

Flushing the cache decreases likelihood of getting staled data, but
can't completely remove it.  I am fine to use cache in non-stop mode, as 
it helps performance, so we have to compromise.

> > >Beside the predicate "is any thread running", another is "no thread is
> > >resumed since last flushing".  Cache should be flushed when either is
> > >true.
> Not sure I understood that.

I meant, even "none of threads is running now", we may have to flush 
cache if "they were resumed" (and all stopped now).

--
Yao (éå)