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 #3 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Mikulas Patocka from comment #2)
> Yes, I was looking at this function for the purpose of "abusing" it for a
> portable memory barrier.

Please don't :)  It won't even help you do that because ...

> Unfortunatelly, POSIX doesn't provide any portable memory barrier. C11 has
> botched barriers - even the strongest atomic model __ATOMIC_SEQ_CST
> synchronizes only with locks an other atomic accesses, it doesn't
> synchronize with normal memory references. Currently, there is no way to do
> a memory barrier portably.

... you always have to consider the compiler too.  C11 requires data-race-free
programs -- without that, the compiler would be *severely* restricted in which
optimizations it can apply to normal code.  Thus, C11's memory model isn't
"botched" at all but is really what you want to use.  I suggest to learn how it
works and why it's built that way.  For example, if you use proper atomic
accesses for the data that is accessed concurrently by several threads, C11's
fences are perfectly fine.
Even glibc will likely use the C11 model in the future.

I'm keeping the bug open because the practice vs. POSIX wording issue still
stands.

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