From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDBgO-0000wl-EB for qemu-devel@nongnu.org; Mon, 19 Jan 2015 07:43:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDBgJ-0008Ic-Be for qemu-devel@nongnu.org; Mon, 19 Jan 2015 07:43:52 -0500 Received: from mail.ispras.ru ([83.149.199.45]:59998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDBgJ-0008IV-4o for qemu-devel@nongnu.org; Mon, 19 Jan 2015 07:43:47 -0500 From: "Pavel Dovgaluk" References: <20150112115944.3504.66763.stgit@PASHA-ISP> <20150112120054.3504.35220.stgit@PASHA-ISP> <54B3BA89.6080705@redhat.com> <000501d02f12$61177b30$23467190$@Dovgaluk@ispras.ru> <54B4E79C.5010201@redhat.com> <000101d03162$f2d2ed50$d878c7f0$@Dovgaluk@ispras.ru> <54BCEFD1.5040702@redhat.com> <000c01d033df$ece29420$c6a7bc60$@Dovgaluk@ispras.ru> <54BCF55D.7040607@redhat.com> In-Reply-To: <54BCF55D.7040607@redhat.com> Date: Mon, 19 Jan 2015 15:43:46 +0300 Message-ID: <000d01d033e5$90d30420$b2790c60$@Dovgaluk@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: ru Subject: Re: [Qemu-devel] [RFC PATCH v7 12/21] replay: recording and replaying clock ticks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Paolo Bonzini' , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, alex.bennee@linaro.org, mark.burton@greensocs.com, real@ispras.ru, batuzovk@ispras.ru, maria.klimushenkova@ispras.ru, afaerber@suse.de, fred.konrad@greensocs.com > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > On 19/01/2015 13:03, Pavel Dovgaluk wrote: > > It will work for protecting the events list (I've already did this). > > But that will not work for protecting the log file. > > replay_run_event can write some data to the log. And also some other function like > replay_checkpoint > > can also write to the log simultaneously (if we will remove the global mutex). > > That's why we cannot simply replace the global mutex with some kind of local one. > > That's why you have to document very well the architecture and the > locking policy. Ok. > For example, why can't replay_run_event (or something > that it calls) take the replay lock locally, when it writes to the log? replay_run_event can take the lock. Suppose that it writes data 'A'. replay_run_event itself corresponds to some event 'E'. We expect that the following sequence of the events should occur: 'E', 'A'. But if something will be written to the log between 'E' and 'A' then replay_run_event in replay mode will stuck, because it will not see its data 'A'. Pavel Dovgalyuk