Re: PR/49816 CVS commit: src/libexec/ld.elf_so

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Wed, Apr 08, 2015 at 03:45:01AM +0000, Masao Uebayashi wrote:
> The following reply was made to PR lib/49816; it has been noted by GNATS.
> 
> From: Masao Uebayashi <uebayasi%gmail.com@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
> 	YAMAMOTO Takashi <yamt%netbsd.org@localhost>
> Subject: Re: PR/49816 CVS commit: src/libexec/ld.elf_so
> Date: Wed, 8 Apr 2015 12:42:28 +0900
> 
>  >  I don't think that's relevant, this is about global visiblity of
>  >  changes. E.g. if another thread tries to get the mutex, it must see all
>  >  changes from the current thread when successfully acquired the mutex.
>  >
>  >  Joerg
>  
>  I can't follow... Your first message was:

The diff commited by yamt-san should not make any difference on
architectures with Total Store Ordering, including x86, which he says he
is running.

>  > None of those should matter on amd64? CAS has an implicit total memory
>  > barrier, so this seems to just add a lot of overhead for no reason.
>  
>  If you're talking about atomic vs. memory barrier, isn't it something
>  addressed by the new C11 atomic API?  Kernel mutex code has
>  MUTEX_RECEIVE()/MUTEX_GIVE() for that purpose (IIUC).

Yes, except we don't have it available. I'm not sure if there even is
support for it in gcc-4.8. For Clang, it would be just a question of
installing stdatomic.h somewhere.

Joerg