By: rwessel (rwessel.delete@this.yahoo.com), August 25, 2022 8:16 am
Room: Moderated Discussions
Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 25, 2022 6:24 am wrote:
> Anon (no.delete@this.spam.com) on August 25, 2022 5:25 am wrote:
> > Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 25, 2022 1:54 am wrote:
> > > Like "load cacheline on local L1 D-cache in exclusive mode and refuse to share that cacheline"?
> > > At some point your request has to be cancelled, else all processing
> > > may stop due to a bug or an AB - BA lockup by two cores.
> > > At that point (cancel exclusive request) you want an exception?
> > > I also imagine there would be a limit on the number of cachelines a core refuses to share...
> >
> > I don't know, what I expect from a hardware claiming to
> > provide transactions is that, when I request something
> > within the predefined limits defined by the hardware vendor
> > to be done atomically it will be done atomically,
> > I know this is hard and the bigger the transaction the harder it will be, not everything in life is easy.
> >
>
> Maybe an interface like "mwait" but waiting that a (finite) list of data cachelines
> (and few code cacheline covering code to be executed) are all available in exclusive
> mode on the local core would be better then, probably with a timeout.
> You would not be sure that such "wait" ever succeed without timeout, but if it does then
> the transaction can start and will complete... unless you use absent cachelines.
> Not sure how easy to implement in hardware, not sure how easy to use in software.
> At least it would not waste resources, and the sibling core would have time to do its stuff.
I'm not sure I understand this concern. The transaction appears (eventually) to all other cores as a single atomic event. In practice another transaction (or a non-transactional access) can interfere, and prevent completion, but they can't cause a deadlock. Worst case a "guaranteed" transaction eventually halts all other cores in the configuration while doing a couple of retries (one would hope that such an extreme measure would be quite rare, but it's a plausible last resort). Even a normal (non-guaranteed) transaction can use random backoff to increase the odds of success.
> Anon (no.delete@this.spam.com) on August 25, 2022 5:25 am wrote:
> > Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 25, 2022 1:54 am wrote:
> > > Like "load cacheline on local L1 D-cache in exclusive mode and refuse to share that cacheline"?
> > > At some point your request has to be cancelled, else all processing
> > > may stop due to a bug or an AB - BA lockup by two cores.
> > > At that point (cancel exclusive request) you want an exception?
> > > I also imagine there would be a limit on the number of cachelines a core refuses to share...
> >
> > I don't know, what I expect from a hardware claiming to
> > provide transactions is that, when I request something
> > within the predefined limits defined by the hardware vendor
> > to be done atomically it will be done atomically,
> > I know this is hard and the bigger the transaction the harder it will be, not everything in life is easy.
> >
>
> Maybe an interface like "mwait" but waiting that a (finite) list of data cachelines
> (and few code cacheline covering code to be executed) are all available in exclusive
> mode on the local core would be better then, probably with a timeout.
> You would not be sure that such "wait" ever succeed without timeout, but if it does then
> the transaction can start and will complete... unless you use absent cachelines.
> Not sure how easy to implement in hardware, not sure how easy to use in software.
> At least it would not waste resources, and the sibling core would have time to do its stuff.
I'm not sure I understand this concern. The transaction appears (eventually) to all other cores as a single atomic event. In practice another transaction (or a non-transactional access) can interfere, and prevent completion, but they can't cause a deadlock. Worst case a "guaranteed" transaction eventually halts all other cores in the configuration while doing a couple of retries (one would hope that such an extreme measure would be quite rare, but it's a plausible last resort). Even a normal (non-guaranteed) transaction can use random backoff to increase the odds of success.