From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8983 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: stdatomic implementation Date: Sun, 13 Dec 2015 15:59:50 +0100 Message-ID: <20151213145950.GH23362@port70.net> References: <1450000882.317.5.camel@inria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1450018814 449 80.91.229.3 (13 Dec 2015 15:00:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Dec 2015 15:00:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8996-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 13 16:00:10 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1a8887-0002SZ-HZ for gllmg-musl@m.gmane.org; Sun, 13 Dec 2015 16:00:07 +0100 Original-Received: (qmail 32072 invoked by uid 550); 13 Dec 2015 15:00:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32045 invoked from network); 13 Dec 2015 15:00:02 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <1450000882.317.5.camel@inria.fr> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:8983 Archived-At: * Jens Gustedt [2015-12-13 11:01:22 +0100]: > Its integration into musl should be straight forward and remains my > primary choice for having it distributed. You can find it at > > stdatomic.gforge.inria.fr > nice i recently run into a problem that you may be interested in: the gcc atomic builtins do not handle atomic pointer types as expected. T *p; __atomic_fetch_add(&p,1); adds 1 to (char*)p instead of sizeof(T). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64843 > Under the hood it uses a new lock algorithm based on futex waits for > the slow path, that has proven to be more efficient than anything else > that I looked at: musl's internal lock, mtx_t or pthread_mutex_t, or > spinlocks. You can find a discussion of that at > > https://hal.inria.fr/hal-01236734 > > Before I go (more) public with this, I would very much like to hear > what you think. i havent read the paper yet but it is worth noting that glibc implements weaker pthread semantics than musl, so on glibc pthread_mutex_lock/unlock is acquire/release. (which makes pthread_mutex_trylock non-conforming, but it's closer to the c11 semantics, same for spinlocks). so it would be interesting to benchmark against glibc primitives too.