Sorry - I should have replied to this Peter
I agree with you - I dont know how much overlap we’ll find with different
architectures.
But if we stick to the more generic ‘lock/unlock’, I dont see how this is going
to help us output thread safe code without going thought a mutex - at which
point we are back to square 1.
Cheers
Mark.
> On 17 Dec 2014, at 12:36, Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> On 17 December 2014 at 11: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.
>
> You'd need to compare the semantics of ll/sc across the various
> architectures to find out if there was anything you could
> actually meaningfully define as useful TCG op semantics there.
>
> -- PMM
+44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210
+33 (0)603762104
mark.burton
