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

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |c

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This obviously isn't a libstdc++ bug because you're not even using C++!

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

[bin.x.fan at oracle dot com]

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

--- Comment #2 from Bin Fan <bin.x.fan at oracle dot com> ---
I couldn't find a category for libatomic, and my understand is that C and C++
share libatomic library.

(In reply to Jonathan Wakely from comment #1)
> This obviously isn't a libstdc++ bug because you're not even using C++!

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

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, so either C or C++ might be appropriate, but not libstdc++.

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

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu.org
           Severity|normal                      |enhancement

--- Comment #5 from Richard Henderson <rth at gcc dot gnu.org> ---
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.  Thus locks are created on a per-
cacheline basis covering one page.

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

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

[bin.x.fan at oracle dot com]

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, ...)

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

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson <rth at gcc dot gnu.org> ---
(In reply to Bin Fan from comment #6)
> 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?

The same page mapped into the address space more than once.  Of course
I don't mean different processes, as libatomic is *not* an IPC library.
Such a thing is easily constructable via mmap of a file, however.

> This make sense if the above understand of aliased pages is true. However,
> what if the memory is not mapped at page boundaries?

How do you suppose you'd map a page anywhere other than at a page boundary?
That's nonsensical.  Virtual address spaces don't work that way.

> 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.

...

> 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;

Yes.  The end address cannot be inferred from the start address.  Thus we
lock every cacheline the object overlaps.