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

[Pedro Alves <palves@redhat.com>]

On 12/09/2013 01:56 PM, Yao Qi wrote:
> On 12/09/2013 09:13 PM, Pedro Alves wrote:
>> We can have more stops than resumes.
>>
>>   #1 - resume everything (1000 threads)
>>   #2 - event in one thread triggers, we call target_wait
>>   #3 - gdb decides to leave thread stopped.
>>   #4 - one hour passes, while threads poke at memory.
>>   #5 - another event triggers, and we call target_wait again
>>
>> No resume happened between #2 and #5.
> 
> Thanks for the explanation.  IIUC, #2, #3, and #5 are the result of 
> handle_inferior_event, where cache is flushed (with my patch applied).

No, #2 happens before handle_inferior_event is called.

> 
> "wait -> handle event -> wait" is like a loop or circle to me, and we
> can flush at any point(s) of this circle, depending on what heuristic
> we are using.

Again, the point is making it so that the cache does not enlarge
the race window with the inferior itself.  IOW, make the cache
transparent WRT to chances of seeing a teared value, prologue, or
whatever.  Between starting to handle an event and finishing
it, a very short time passes.  Between finishing handling an
event and the next event, an unbound amount of time passes.
If we don't flush the cache just before handling the event,
having the cache active has a much much wider race window width
than without the cache active.

-- 
Pedro Alves