From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8256 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: New optimized normal-type mutex? Date: Mon, 3 Aug 2015 19:36:46 +0300 (MSK) Message-ID: References: <8c49d81e.dNq.dMV.21.hNiSfA@mailjet.com> <1438207875.10742.3.camel@inria.fr> <20150729233054.GZ16376@brightrain.aerifal.cx> <1438213760.10742.5.camel@inria.fr> <20150730001014.GA16376@brightrain.aerifal.cx> <1438243654.10742.9.camel@inria.fr> <1438247427.10742.13.camel@inria.fr> <1438250459.10742.16.camel@inria.fr> <20150730134649.GC16376@brightrain.aerifal.cx> <1438272464.10742.20.camel@inria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="168458499-1202266809-1438619806=:19951" X-Trace: ger.gmane.org 1438619821 8103 80.91.229.3 (3 Aug 2015 16:37:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Aug 2015 16:37:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8269-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 03 18:37:00 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 1ZMIjT-0001pc-RR for gllmg-musl@m.gmane.org; Mon, 03 Aug 2015 18:36:59 +0200 Original-Received: (qmail 5352 invoked by uid 550); 3 Aug 2015 16:36:58 -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 5333 invoked from network); 3 Aug 2015 16:36:57 -0000 In-Reply-To: <1438272464.10742.20.camel@inria.fr> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) Xref: news.gmane.org gmane.linux.lib.musl.general:8256 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --168458499-1202266809-1438619806=:19951 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT > I will try to discuss this below. Thanks for the detailed response. Misc. comments below. > > > With so little work in the critical section, it does > > > not make sense to me that you would use something like a normal-type futex-y > > > mutex. Even a call/return to grab it gives you some overhead. I'd expect you > > > would use a fully inlined spinlock acquisition/release around the memory copy. > > > > No, spinlocks are completely unusable in a POSIX libc that implements > > priorities. They will deadlock whenever a lower-priority thread gets > > preempted by a higher-priority one while holding the lock. Thanks Rich for pointing that out. [...] > Now let us try to figure out what happens in the case that started > this new discussion, namely that there is so much contention such that > the probability of an EAGAIN-failure of the mutex call increases. As long as we're talking in terms of futexes, it's EWOULDBLOCK, not EAGAIN. > In fact even if inside the critical section the application itself > does nothing, the lock code first does the spinning. So regardless of > the application, any thread does 100 spins (so some work) before it > starts fighting to be put to sleep on the futex. None of the threads > reaching that point, changes the value of of the counter, so all > threads that reach the point and call futex_wait "simultaneously" know > about the same actual value. > > The value can only change by new threads entering the acquisition > loop. There are no more such threads at a time than can be effectively > be scheduled. These will all spend some time spinning, so there can't > be a bad cascade of such threads that change the counter. OK — initially I missed that spinning a bit before *each* futex_wait is going to work well for you. How do you imagine it to scale when the number of CPUs increases? Naively, it appears that the more CPUs are in contention, the more you would need to spin? > In fact, there will certainly be a tradeoff between the number of > spins and the overall waste in CPU time and bandwidth. I will > experiment a bit with that. Curious to hear what you find. Thanks! Alexander --168458499-1202266809-1438619806=:19951--