> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 13/01/2015 10:21, Pavel Dovgaluk wrote:
> >>> +/*! Reads next clock event from the input. */
> >>> > > +int64_t replay_read_clock(unsigned int kind)
> >>> > > +{
> >>> > > + if (kind >= REPLAY_CLOCK_COUNT) {
> >>> > > + fprintf(stderr, "invalid clock ID %d for replay\n", kind);
> >>> > > + exit(1);
> >>> > > + }
> >>> > > +
> >>> > > + replay_exec_instructions();
> >>> > > +
> >>> > > + if (replay_file) {
> >>> > > + if (skip_async_events(EVENT_CLOCK + kind)) {
> >>> > > + replay_read_next_clock(kind);
> >>> > > + }
> >>> > > + int64_t ret = replay_state.cached_clock[kind];
> >>> > > +
> >>> > > + return ret;
> >>> > > + }
> >>> > > +
> >>> > > + fprintf(stderr, "REPLAY INTERNAL ERROR %d\n", __LINE__);
> >>> > > + exit(1);
> >>> > > +}
> >> >
> >> > Is this thread safe?
> > It is, because order of main_loop and cpu_exec executions is protected
> > by global mutex.
> >
>
> Please document exactly which globals are protected by the rr QemuMutex,
> and which by the global mutex. But I think as many variables as
> possible should be protected by the rr QemuMutex, for two reasons:
>
> 1) people are working on threaded TCG. While SMP record/replay is a
> whole different story, even UP TCG will be multithreaded.
>
> 2) in the end it makes reviewing the code simpler.
There is one problem with protecting log file inside the replay code.
We probably should have the following sequence of calls:
lock_replay_mutex
replay_save_events
replay_run_event
unlock_replay_mutex
But replay_run_event can also generate some log events and we will have
deadlock here.
That is why we rely on global mutex.
Pavel Dovgalyuk
