[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 17 Jul 2014 14:14:37 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Fixing atomic asm constraints
On Sat, Jul 12, 2014 at 03:15:22PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2014-07-11 18:53:26 -0400]:
> > If we do opt for volatile asm everywhere, should we also use the
> > "+m"(ptr) operand form just for the sake of being explicit that the
> > asm accesses the atomic object?
>
> i'd use "+m"(*ptr) to be explicit and i agree that volatile
> is not needed but should not hurt either
I think volatile actually may be needed. Per POSIX, a function like
this:
void foo()
{
pthread_mutex_t m;
pthread_mutex_init(&m, 0);
pthread_mutex_lock(&m);
pthread_mutex_unlock(&m);
pthread_mutex_destroy(&m);
}
"synchronizes memory". This seems to mean "acts as a full barrier".
Note that the synchronizing effect can be observed even without an
object to synchronize on, since an order relationship could be
established by other means such as pipes, waitpid, ...
However, without volatile, I think a compiler performing LTO would be
justified in compiling foo to a nop. Having ptr declared with a
pointer-to-volatile type may preclude optimizing it out, but it's not
clear to me whether C requires this when the underlying object to
which ptr points is known at compile time and is not volatile.
So I think we should probably add volatile to all of the asm.
Does this analysis seem correct?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
