This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/3] skip_prolgoue (amd64)
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: Mark Kettenis <mark dot kettenis at xs4all dot nl>, gdb-patches at sourceware dot org
- Date: Mon, 09 Dec 2013 15:34:06 +0000
- Subject: Re: [PATCH 2/3] skip_prolgoue (amd64)
- Authentication-results: sourceware.org; auth=none
- References: <1385735051-27558-1-git-send-email-yao at codesourcery dot com> <1385735051-27558-3-git-send-email-yao at codesourcery dot com> <201311291436 dot rATEaZ5Z030292 at glazunov dot sibelius dot xs4all dot nl> <201311291605 dot rATG5XVb030184 at glazunov dot sibelius dot xs4all dot nl> <52994E79 dot 4000004 at codesourcery dot com> <5299B9D0 dot 2020304 at redhat dot com> <529C37A2 dot 9000207 at codesourcery dot com> <529E9462 dot 9010001 at codesourcery dot com> <529F1B1F dot 2040606 at redhat dot com> <52A426E8 dot 2030808 at codesourcery dot com> <52A5AF41 dot 6080207 at redhat dot com> <52A5BF2F dot 9060708 at codesourcery dot com> <52A5C202 dot 8010109 at redhat dot com> <52A5CC0D dot 4080004 at codesourcery dot 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