[Bug c++/66842] libatomic uses multiple locks for locked atomics
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.
[Bug c++/66842] libatomic uses multiple locks for locked atomics
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842
Bin Fan bin.x.fan at oracle dot com changed:
What|Removed |Added
Component|c |c++
--- Comment #4 from Bin Fan bin.x.fan at oracle dot com ---
Since I don't see any response from C so far, I change the example to C++ code,
and change the category to c++. Could C++ folks take a look?
-bash-4.2$ cat c++11_locked_atomics.cpp
#include atomic
using namespace std;
#ifndef SIZE
#define SIZE 1024
#endif
typedef struct {
char a[SIZE];
} lock_obj_t;
extern C {
extern void display_nlocks ();
}
int main()
{
lock_obj_t v2 = {0};
atomiclock_obj_t v1 = ATOMIC_VAR_INIT(v2);
v2 = atomic_load (v1);
display_nlocks ();
return 0;
}
gcc -shared -ldl -fPIC libmythread.c -o libmythread.so -g
g++ -std=c++11 -latomic c++11_locked_atomics.cpp -DSIZE=2048 -g -L./
-Wl,-rpath=./ -lmythread
+ LD_PRELOAD=./libmythread.so
+ a.out
pthread_mutex_lock is called 32 times
The g++ version is still 4.9.2.
[Bug c/66842] libatomic uses multiple locks for locked atomics
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
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
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++.
