[Bug c++/66842] libatomic uses multiple locks for locked atomics

["bin.x.fan at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842

--- Comment #6 from Bin Fan <bin.x.fan at oracle dot com> ---
(In reply to Richard Henderson from comment #5)
> When libatomic was first written, it wasn't clear what the restrictions
> from the various languages would be, nor even if that was the best of
> ideas -- things that would Just Work lock-free would fail on other,
> less popular platforms.
> 
> Thus libatomic is written such that accesses to the same object, via
> different aliased pages, will work.  

Could you clarify what does aliased pages mean? Do you mean the same object is
mapped into two or more different processes with different virtual addresses?
And the locks in libatomic are also shared by the processes? Or something else?

> Thus locks are created on a per-cacheline basis covering one page.

This make sense if the above understand of aliased pages is true. However, what
if the memory is not mapped at page boundaries? Then the object may have
different page offset therefore it is still protected by different locks.

And this does not explain why a locked object is protected by multiple locks.
If memory is always mapped at edge boundaries, then the offset of the object in
the page will always be the same so one lock should work. If memory is not
mapped at page boundaries, then if an object is mapped into two
"non-overlapped" address space inside a page, multiple locks would still don't
work.

> 
> This does lead to inefficiencies wrt a more straight-forward solution,
> but very careful thought needs to go into changing it.

Besides aliased pages, does libatomic consider supporting nested locked atomic
objects? For example, should the following work?

typedef struct {
  _Atomic locked1_t obj1;
  /* other fields */
} locked2_t;

_Atomic locked2_t obj2;

atomic_store(&obj2, ...)
atomic_load(&obj2.obj1, ...)