Actually - I dont see any other option.
Playing with the ideas - it seems to me that if we were to implement ‘generic’
Lock/unlock instructions which could then somehow we ‘combined’ with
loads/stores then we would be relying on an optimisation step to ‘notice’ that
this could be combined into e.g. a store EX on ARM, or whatever. That strikes
me as risky .
But then - if we add load/store exclusive type operations - thats great for
e.g. ARM on X86, but does it really cover other architectures well?
I am worried that if we go this path, we will soon end up with a lot of
architecturally specific TCG ops….
Cheers
Mark.
> On 17 Dec 2014, at 12:25, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
>
> On 17/12/2014 12:18, Alexander Graf wrote:
>>
>> So I think the best way to go forward would be to add transaction_start
>> and transaction_end opcodes to TCG and implement them as mutex locks
>> today. When you get the chance to get yourself a machine that supports
>> actual TM, try to replace them with transaction start/end blocks and
>> have the normal mutex code as fallback if the transaction fails.
>
> Or implement load_locked/store_conditional TCG ops. They can be
> implemented as transactions, hardware ll/sc, or something slow that uses
> the MMU.
>
> Paolo
+44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210
+33 (0)603762104
mark.burton
