From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13026 invoked by alias); 9 Dec 2013 15:34:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12970 invoked by uid 89); 9 Dec 2013 15:34:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Dec 2013 15:34:16 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB9FY8ue003713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Dec 2013 10:34:08 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB9FY6xD018942; Mon, 9 Dec 2013 10:34:07 -0500 Message-ID: <52A5E2EE.5040501@redhat.com> Date: Mon, 09 Dec 2013 15:34:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] skip_prolgoue (amd64) References: <1385735051-27558-1-git-send-email-yao@codesourcery.com> <1385735051-27558-3-git-send-email-yao@codesourcery.com> <201311291436.rATEaZ5Z030292@glazunov.sibelius.xs4all.nl> <201311291605.rATG5XVb030184@glazunov.sibelius.xs4all.nl> <52994E79.4000004@codesourcery.com> <5299B9D0.2020304@redhat.com> <529C37A2.9000207@codesourcery.com> <529E9462.9010001@codesourcery.com> <529F1B1F.2040606@redhat.com> <52A426E8.2030808@codesourcery.com> <52A5AF41.6080207@redhat.com> <52A5BF2F.9060708@codesourcery.com> <52A5C202.8010109@redhat.com> <52A5CC0D.4080004@codesourcery.com> In-Reply-To: <52A5CC0D.4080004@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00342.txt.bz2 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