"A" Extension - Lock implementation

[Jim Kenua]

Hello, I read a number of posts on the group about the A extension and its implementation and I am quite confused.

Could the lock be implemented using the MOESI - Owned state to lock the memory address? Would this be valid?

By using the Owned stated more than 1 lock could be achieved but there are still problems with the collisions if multiple locks are on the same lane.

I read a few times that only one lock is allowed but also read that this is not necessarily true, is this true?

Thank you all!

BR,
Jim

[Valentin Nechayev]

hi,

Tue, Jan 17, 2023 at 08:12:18, jimkenua wrote about "[hw-dev] "A" Extension - Lock implementation":

> Hello, I read a number of posts on the group about the A extension and its
> implementation and I am quite confused.
>
> Could the lock be implemented using the MOESI - Owned state to lock the
> memory address? Would this be valid?

Considering any MESI-like caching scheme one should realize that:
1) The core burden is among messages to exchange between states, not
the states on their own;
2) The basic states are just bases; real implementations could support
a few dozens of substates and these details, usually, are of trade secret.

Just a single example - when a hart wants to modify a cache line which
was previously in Exclusive state, it keeps a respective intention
which prevents oncoming requests to own from other harts; when it
really gets confirmation, the cache line is already in Modified state
but not modified yet; and only then it may do a real modification. So
it should be called alike "Modification-in-progress". But the common
scheme does not reveal this detail until you really start implementing
it and then facing all the complexity.
(And, more so, two harts which both want to modify a line shall not
lock each other. Deadlock is not what we want. So a kind of FIFO, at
least, shall be present. Just to show yet more obstacles...)

The same for your question: let you consider first how a hart will
handle all cases like "Modified - in another hart", "Exclusive - in
another hart", "Shared - with copy in this hart", and so on. Each one
will require a respective kind of exchange.

If MOESI is implemented in basics, well, to modify a line the hart
will need to obtain it in its own cache either as Modified or Owned,
keeping an intention to really modify it which will cause rejection of
oncoming requests until real modification. When having a modifiable
(not modified yet!) copy is finished, the final task to do
CAS/analog can be simply performed locally.

> By using the Owned stated more than 1 lock could be achieved but there are
> still problems with the collisions if multiple locks are on the same lane.

Definitely. "False sharing" is a huge slowdown factor which is to be
prevented at software level.

> I read a few times that only one lock is allowed but also read that this is
> not necessarily true, is this true?

RISC-V spec guarantees convergence if SC is done within 64 bytes and
respective executed instruction count after LL. This means, most
simply, LL causes rejections to requests from other harts to re-own
the cache line, for an implementation-defined count of cycles.

Having no more than 1 lock per cache line substantially increases
quality of lock control.


-netch-