From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5767 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Explaining cond var destroy [Re: [musl] C threads, v3.0] Date: Thu, 7 Aug 2014 12:52:22 +0200 Message-ID: <20140807105222.GI22308@port70.net> References: <20140806100335.GV1674@brightrain.aerifal.cx> <1407321172.24324.287.camel@eris.loria.fr> <20140806161552.GB1674@brightrain.aerifal.cx> <1407344216.24324.317.camel@eris.loria.fr> <20140806173254.GC1674@brightrain.aerifal.cx> <1407358510.24324.328.camel@eris.loria.fr> <20140806220453.GD1674@brightrain.aerifal.cx> <1407365015.24324.334.camel@eris.loria.fr> <20140806231539.GE1674@brightrain.aerifal.cx> <1407397851.24324.354.camel@eris.loria.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 1407408763 21009 80.91.229.3 (7 Aug 2014 10:52:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Aug 2014 10:52:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5772-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 07 12:52:36 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 1XFLJD-0004M1-F1 for gllmg-musl@plane.gmane.org; Thu, 07 Aug 2014 12:52:35 +0200 Original-Received: (qmail 21716 invoked by uid 550); 7 Aug 2014 10:52:34 -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 21705 invoked from network); 7 Aug 2014 10:52:34 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <1407397851.24324.354.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5767 Archived-At: * Jens Gustedt [2014-08-07 09:50:51 +0200]: > Am Mittwoch, den 06.08.2014, 19:15 -0400 schrieb Rich Felker: > > No, it's not. The wait happens prior to the deallocation, in the same > > thread that performs the deallocation. The interleaving looks like > > this: > > > > Thread A Thread B > > -------- -------- > > waiters++ > > save waiters count > > atomic unlock > > futex wait fails with EAGAIN > > cas succeeds & gets lock > > waiters-- > > [unlock operation] > > [free operation] > > futex wake to freed address > > > > The free operation in thread A is valid since A knows it is the last > > user of the mutex and thread B's use/ownership of the mutex formally > > ends with the atomic unlock. > > No, operating on an object that has been freed is UB. This is > independent of this object being a mutex or not. This must never > happen. So the free is making a wrong assumption. > > I think the fundamental flaw with this approach is that it mixes two > different concepts, the waiters count and a reference count. These are > two different things. > > With a reference count, the schema looks like this. > > Initially the "obj->refs" counter is at least 2 because both threads > hold references on the object. > > Thread A Thread B > -------- -------- > waiters++ > save waiters count > atomic unlock > futex wait fails with EAGAIN > cas succeeds & gets lock > waiters-- > [unlock operation] > if (atomic_fetch_sub(&obj->refs,1) == 1) > [free operation on obj] > > futex wake to freed address > if (atomic_fetch_sub(&obj->refs,1) == 1) > [free operation on obj] > > Which thread does the free operation (if any), only depends on the > order in which the atomic_fetch_sub operations are effective. (And > musl doesn't seem to have the primitives to do atomic_fetch_sub?) > > Now I am aware that such a scheme is difficult to establish in a > setting where obj can be malloced of not. This scenario supposes that > both threads *know* that the allocation of obj has been done with > malloc. > i havent followed all the discussions so i dont know if this is libc internal only or exposed to the user (who does the free) but the locking behaviour exposed to the user should be such that this pattern works: mutex_lock(obj->lock); c = --obj->refs; mutex_unlock(obj->lock); if (!c) free(obj); if it does not work then there will be hard to debug bugs https://sourceware.org/bugzilla/show_bug.cgi?id=13690 http://austingroupbugs.net/view.php?id=811 http://lwn.net/Articles/575477/ https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg04583.html > The easiest way to assure that, would be to impose that the "real" > data object that the thread lock, unlock, wait etc operations would > use would always have to be malloced. > > For C threads this can be done by mtx_init and cnd_init. They would > be allocating the dynamic object, set "refs" to 1 and set a link to > that object. For mtx_t and cnd_t dynamic initialization is imperative. > dynamic allocation per mutex or cond var sounds bad