This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/16432] pthread_spin_unlock should imply a memory barrier


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]