From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id ADBAC81798 for ; Wed, 17 Jul 2013 19:50:48 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of murthy.chet@gmail.com) identity=pra; client-ip=209.85.219.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of murthy.chet@gmail.com designates 209.85.219.52 as permitted sender) identity=mailfrom; client-ip=209.85.219.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oa0-f52.google.com) identity=helo; client-ip=209.85.219.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-oa0-f52.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYGAIPX5lHRVds0lGdsb2JhbABagzqGBb0hgREWDgEBAQEHCwsJEiqCIwEBBToGARsdAQMMBgUYCRUQDwETEQEFARwGiBABAw8MmBOMT4J/hE0KGScNZId0AQUMjiaBSAeDewOJJ49ejj8/hFhSAQ X-IPAS-Result: AnYGAIPX5lHRVds0lGdsb2JhbABagzqGBb0hgREWDgEBAQEHCwsJEiqCIwEBBToGARsdAQMMBgUYCRUQDwETEQEFARwGiBABAw8MmBOMT4J/hE0KGScNZId0AQUMjiaBSAeDewOJJ49ejj8/hFhSAQ X-IronPort-AV: E=Sophos;i="4.89,686,1367964000"; d="scan'208";a="26380479" Received: from mail-oa0-f52.google.com ([209.85.219.52]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jul 2013 19:50:47 +0200 Received: by mail-oa0-f52.google.com with SMTP id g12so2962412oah.11 for ; Wed, 17 Jul 2013 10:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=r/tqPBreAQ2IHPmz7HPT/jAD1UTWa6ZjUWo2bjLCFCM=; b=t+8QEnDKJmUv2Tz1GFjE4+9ouSrZRCWnqTqEuV8oMxjCmE+g7nCV+vq3di9H/NQ5Cm sHvNav//54wBLBqzhouoy3FqSWHZG1rF9nSCB6uyOj6Zv55vMj7M0i+L2MOomSOEgyEj 6UV+q5ONWZuWngJZVEoKz8on0iZH81uAyUepBdAVc6g7VyXD5zjdJBo503V5XiHxrK5C GT+aCnESmCpH5qXDOU4/Pt+/g/KPKtlk1nkYd+gPbbnXUrYiJXuxDxSZevOho9pqd8mx 6VHER1v1CfGDFuQtDmoxqFinIHQBhkQX5+bE73xWwiKTHhlaEclN2/RnnN3uPJ/0BTMy L98A== X-Received: by 10.60.56.82 with SMTP id y18mr9423426oep.86.1374083446624; Wed, 17 Jul 2013 10:50:46 -0700 (PDT) Received: from groupon.localnet (adsl-76-254-31-119.dsl.pltn13.sbcglobal.net. [76.254.31.119]) by mx.google.com with ESMTPSA id ps5sm9018093oeb.8.2013.07.17.10.50.44 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 10:50:45 -0700 (PDT) From: Chet Murthy To: Xavier Leroy Cc: caml-list@inria.fr Date: Wed, 17 Jul 2013 10:50:42 -0700 Message-ID: <2474292.A2ICsWKU9J@groupon> User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <51E6D575.9010406@inria.fr> References: <5000924.vCd1HWCNpc@groupon> <51E6D575.9010406@inria.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Caml-list] recursive mutexes in ocaml Xavier, Wow, that's excellent. Made my morning! I've implemented Java's monitors, so yeah, they're as you describe, and I cannot imagine doing it any other way. What were they -thinkin'- in the POSIX committee? Ah, well. OK. I'll just add the (few) lines of code needed to get basic recursive mutexes for locking purposes, and leave it at that. Given Butenhof's analysis, I -fully- agree with leavin' 'em out of ocaml. Yikes! --chet-- On Wednesday, July 17, 2013 07:33:41 PM Xavier Leroy wrote: > Hi Chet, > > > I figured I'd ask -why- ocaml's mutexes aren't recursive. Or at > > least, why there isn't an option for recursive mutexes? > > Dave Butenhof, one of the main authors of POSIX threads, makes rather > strong points against recursive mutexes: > http://tinyurl.com/butenhof-recursive-mutexes > > The killer issue in my opinion is how to make recursive mutexes play > well with pthread_cond_wait() / Condition.wait: POSIX's > pthread_cond_wait() only releases the mutex once, which leads to all > sorts of deadlock if it's been acquired N>1 times. I believe Java > has a more useful behavior, whereas the mutex is released N times, > then reacquired N times. But this cannot be implemented easily on top > of POSIX threads. And don't get me started on Win32 threads... > > It might make sense to have recursive mutexes as a separate type, > different from ordinary mutexes, so that it's not usable in > conjunction with Condition.wait. Apparently, Batteries has/had that. > > - Xavier Leroy