> 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.
>
> Alex
+44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210
+33 (0)603762104
mark.burton
