> From: Paolo Bonzini [mailto:pbonz...@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
