From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5949 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: sem_getvalue conformance considerations Date: Thu, 28 Aug 2014 01:06:36 +0400 (MSK) Message-ID: References: <20140827023338.GA21076@brightrain.aerifal.cx> <1409123141.4476.18.camel@eris.loria.fr> <20140827074310.GK12888@brightrain.aerifal.cx> 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 1409173713 25009 80.91.229.3 (27 Aug 2014 21:08:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2014 21:08:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5956-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 27 23:08:27 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XMkS8-0004B7-6J for gllmg-musl@plane.gmane.org; Wed, 27 Aug 2014 23:08:24 +0200 Original-Received: (qmail 31928 invoked by uid 550); 27 Aug 2014 21:08:23 -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 31920 invoked from network); 27 Aug 2014 21:08:23 -0000 In-Reply-To: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) Xref: news.gmane.org gmane.linux.lib.musl.general:5949 Archived-At: On Wed, 27 Aug 2014, Alexander Monakov wrote: > On IRC Rich noted that I've too conveniently elided cancellation, so here's how > I think cancellation handler should look like: s/cancellation handler/"unwait" procedure/: returning with EINTR is botched in my earlier mail and should employ the same procedure to undo state change > val = sem->val[0]; > while (val < 0) { > /* We believe we are a waiter that no sem_post has "seen". */ > oldval = val; > if ((val = a_cas(sem->val, val, val+1)) == oldval) > return; > } > /* We are a waiter, and a non-negative val[0] indicates that one sem_post > * noticed us. Consume the corresponding wake count increment. */ > a_dec(sem->val+1); A plain atomic decrement on wake count like above is not correct. However: 1. I think it's correct as long as no new waiters appear while we are performing unwait. If new waiters are matched by new posts it's ok; we only care if the amount of new waiters is higher than the amount of new posts, as then we are risking to cause a missing wake for one of those, or setting wake count to -1 if they all consume wakes before we do the increment. 2. Thus it needs a fancy atomic op: decrement val[1] if val[0] is still equal to "val" we retrieved earlier. Otherwise, retry from the beginning. Futhermore, doing the above in a true atomic fashion might not be required! Isn't it okay to decrement wake count, and if we observe new waiters, increment it back and cause a futex wake? Thus: retry: val = sem->val[0]; while (val < 0) { /* We believe we are a waiter that no sem_post has "seen". */ oldval = val; if ((val = a_cas(sem->val, val, val+1)) == oldval) return; } /* We are a waiter, and a non-negative val[0] indicates that one sem_post * noticed us. Consume the corresponding wake count increment. */ a_dec(sem->val+1); if (val > sem->val[0]) { /* New waiters appeared. Avoid causing a missing wake and restart. We * don't enter here if more new posts are posted than new waiters come. */ a_inc(sem->val+1); futex_wake(sem->val+1, 1); goto retry; } Alexander