By: sr (nobody.delete@this.nowhere.com), April 10, 2021 1:22 am
Room: Moderated Discussions
anon2 (anon.delete@this.anon.com) on April 8, 2021 4:09 am wrote:
> Andrey (andrey.semashev.delete@this.gmail.com) on April 8, 2021 2:41 am wrote:
> > All LL/SC architectures require a retry, which is a sign that forward progress is not guaranteed.
>
> Again: zero sane architectures require a fallback path for LL/SC. You're just wrong.
Is there some way to provide sane transactional memory without retry? Retry point is the main idea of whole concept, but it doesn't prevent forward progress in any way.
But forward guarantee, as seen that code can progress with written path without fallback code can be provided - it just needs that there isn't harware limits for tracked memory accesses. Transaction can be suspended but memory tracking can't. And strict memory limits for transaction that could provide forward progress with limited hardware tracking possibilities are nearly impossible - even TSX does support transaction in transactions and if there is hardware memory limits everything breaks.
> Andrey (andrey.semashev.delete@this.gmail.com) on April 8, 2021 2:41 am wrote:
> > All LL/SC architectures require a retry, which is a sign that forward progress is not guaranteed.
>
> Again: zero sane architectures require a fallback path for LL/SC. You're just wrong.
Is there some way to provide sane transactional memory without retry? Retry point is the main idea of whole concept, but it doesn't prevent forward progress in any way.
But forward guarantee, as seen that code can progress with written path without fallback code can be provided - it just needs that there isn't harware limits for tracked memory accesses. Transaction can be suspended but memory tracking can't. And strict memory limits for transaction that could provide forward progress with limited hardware tracking possibilities are nearly impossible - even TSX does support transaction in transactions and if there is hardware memory limits everything breaks.
