This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/16432] pthread_spin_unlock should imply a memory barrier
- From: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 24 Sep 2014 20:36:58 +0000
- Subject: [Bug nptl/16432] pthread_spin_unlock should imply a memory barrier
- Auto-submitted: auto-generated
- References: <bug-16432-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16432
--- Comment #5 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Mikulas Patocka from comment #4)
> Suppose that I need to create some structure using non-atomic accesses, then
> execute a memory barrier and then publish pointer to the structure using
> atomic operation.
Sure you can do that.
> s->f = q2;
> atomic_store_explicit(&ptr, s, __ATOMIC_SEQ_CST);
And that's a release store too, so you can do
p = atomic_load_explicit(&ptr, memory_order_acquire);
if (p!=NULL) foo = p->a;
> According to the C11 standard this program is wrong. If I wanted to write
> the program correctly according to the standard, then every member of the
> structure s would have to be _Atomic. Furthermore, every member of
> structures something1 and something2 would have to be _Atomic. Formally
> speaking, every variable reachable via pointers from the structure s would
> have to be declared with the _Atomic prefix.
No. The load of ptr has to be atomic, but happens-before holds for nonatomic
accesses too. Please learn about how the model works.
> So, the standard is really botched and unusable for this purpose :-(
In any case, this bug report is not a place to discuss the C11 memory model.
--
You are receiving this mail because:
You are on the CC list for the bug.