Re: [Qemu-devel] [RFC PATCH v7 12/21] replay: recording and replaying clock ticks

[Pavel Dovgaluk]

> From: Paolo Bonzini [mailto:address@hidden
> 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