Exclusive monitor implementation is wrong. More optimal solution is possible.

[armleo]

Instead of locking the memory section that was loaded from, lock the entire memory. This way if some CPUs start load-reserve spamming operation lock will still be valid and performance will not be degraded.

[armleo]

This issue is result of investigation of #56

[armleo]

New results: This solution is wrong, because what if attacker CPU spams stores? Again performance degradation. New solution: Implement multiple locks per CPU (the ID is used to identify between CPUs). Load-reserves lock only the local CPU, and for stores, the lock is invalidated only if the location of the lock is overwritten by the store.

[armleo]

When atomic read then the lock (idx=id) is set and the address (idx=id) is set with read's address When atomic write then if lock is still valid and address matches then lock is reset and the operation completes with EXOKAY. Then the monitor goes thru all of the locks and invalidates them if address matches. Same for ordinary writes. Else if the lock is valid and address mismatches, return OKAY and dont pass the write.

[armleo]

Case: We track last load and lock entire adress range

Good: M0: Read locking M1: Read locking M1: Write locking M0: Fails <- Just fine

Bad: M0: Read locking M1: Spamming read locking M0: Fails to write locking All retries of M0 fail for the same reason

Solution: We keep tracking address of the master that was read

M0: Read locking M1: Spamming Read locking M0: Still fails because the lock is overwritten

Solution: Introduce stored the tracked address in storage with idx ID M1: Tries to spam read and cant overwrite the lock, but still uses dummy write that causes some section of memory for lock to be removed.

Solution: We set the storage size to count of IDs and dummy writes cant overwrite the locks because address does not match. In case of write we go thru the list of IDs and check if it matches any addresss then the lock is reset M1: Tries spamming read locking cant affect other masters M1: Tries spamming writting but does not affect other masters as address does not match M1: read modufy write spamming does not cause issues as the M1 does not have access to same addressed as M0

IMHO It should use 4KB page sized locks, this will make sure that no matter the transaction no need to store addr+len and compare them all