On 17.12.14 11:31, Mark Burton wrote: > >> On 17 Dec 2014, at 11:28, Alexander Graf <ag...@suse.de> wrote: >> >> >> >> On 17.12.14 11:27, Frederic Konrad wrote: >>> On 16/12/2014 17:37, Peter Maydell wrote: >>>> On 16 December 2014 at 09:13, <fred.kon...@greensocs.com> wrote: >>>>> From: KONRAD Frederic <fred.kon...@greensocs.com> >>>>> >>>>> This adds a lock to avoid multiple exclusive access at the same time >>>>> in case of >>>>> TCG multithread. >>> Hi Peter, >>> >>>> This feels to me like it's not really possible to review on >>>> its own, since you can't see how it fits into the design of >>>> the rest of the multithreading support. >>> true the only thing we observe is that it didn't change anything right now. >>> >>>> The other approach here rather than having a pile of mutexes >>>> in the target-* code would be to have TCG IR support for >>>> "begin critical section"/"end critical section". Then you >>>> could have the main loop ensure that no other CPU is running >>>> at the same time as the critical-section code. (linux-user >>>> already has an ad-hoc implementation of this for the >>>> exclusives.) >>>> >>>> -- PMM >>>> >>> What do you mean by TCG IR? >> >> TCP ops. The nice thing is that TCG could translate those into >> transactions if the host supports them as well. >> > > Hows that different in reality from what we have now? > Cheers > Mark.
The current code can't optimize things in TCG. There's a good chance your TCG host implementation can have an optimization pass that creates host cmpxchg instructions or maybe even transaction blocks out of the critical sections. Alex
