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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 3758C7ED25 for ; Wed, 17 Jul 2013 09:28:34 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of murthy.chet@gmail.com) identity=pra; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of murthy.chet@gmail.com designates 209.85.214.174 as permitted sender) identity=mailfrom; client-ip=209.85.214.174; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f174.google.com) identity=helo; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-ob0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0DAPJF5lHRVdauk2dsb2JhbABSCIk+vH6BDhYOAQEBAQcLCwkUBCSCIwEBBAE6BgEbHgMMBiYVEA8BExEBBQEWBogWAQMJBpgkjE+Cf4Q6ChknDWSHdAEFDI4gDIE9FoNkA4knnh0/hFiBUQ X-IPAS-Result: Au0DAPJF5lHRVdauk2dsb2JhbABSCIk+vH6BDhYOAQEBAQcLCwkUBCSCIwEBBAE6BgEbHgMMBiYVEA8BExEBBQEWBogWAQMJBpgkjE+Cf4Q6ChknDWSHdAEFDI4gDIE9FoNkA4knnh0/hFiBUQ X-IronPort-AV: E=Sophos;i="4.89,682,1367964000"; d="scan'208";a="21420295" Received: from mail-ob0-f174.google.com ([209.85.214.174]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jul 2013 09:28:33 +0200 Received: by mail-ob0-f174.google.com with SMTP id wd20so1870072obb.19 for ; Wed, 17 Jul 2013 00:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=YHKGUnbWCJUpZfizj3ByjaxFGJBHKCytYqlGk8crMLk=; b=PI1iAtXq9Bq5/hxkDDn+1s6oeISyAZ+jQQMWiZu3VgVzTQiVn3lvEs4jOKxDfcUWfb obZTVuFF7ytz2qCkqI0Pa/zTk4dZXU3gZSk5/2ynLaJOmC8kV4Ef/4E+YhYeg3vUbkDS g/1lswa8mYJHwoJM/qLDx1733lr1Xe76A+DWMrPUPAyXGsaW7M4YcY+VAxuZ0awQi0hw gBrY+5zOX5KCOxRtBmmnB0OWsh4vFyi7VSElz6j26aZ3aHRfiw/h/hCNXSbnSdbGmv3r fqTl2nd7I8x/VI3jEDfb/8MoPh8cfwhqblrYnC0M7AtbLd174GnDzePWc9iEatWnJNcK qmcg== X-Received: by 10.60.97.74 with SMTP id dy10mr6831212oeb.27.1374046111946; Wed, 17 Jul 2013 00:28:31 -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 o8sm5874999obx.11.2013.07.17.00.28.30 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 00:28:31 -0700 (PDT) From: Chet Murthy To: caml-list@inria.fr Date: Wed, 17 Jul 2013 00:28:28 -0700 Message-ID: <5000924.vCd1HWCNpc@groupon> User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [Caml-list] recursive mutexes in ocaml Recently I'm writing some multi-threaded code, and ended up wishing I had recursive mutexes. Now .... I realize that this is a simple thing to "get" -- just hack the code, maaaan. But before (or, erm .... whilst) I do that, I figured I'd ask -why- ocaml's mutexes aren't recursive. Or at least, why there isn't an option for recursive mutexes? I realize that at some level, you can -always- eschew recursive mutexes by passing along extra parameters so that code can know whether it's locked a particular mutex. That said, it's (more than) a bit of a pain, and surely complicates code .... Is there some other -reason- that recursive mutexes aren't implemented? Or is it just a matter of taste? Thanks, --chet-- P.S. I found Markus' email about this: >> I'd consider recursive lock acquisitions bad practice. There has never been a case in numerous complex bindings where I would have needed this feature. In mission-critical code I even prefer error-checking mutexes that prevent me from acquiring locks twice or releasing them once too often. As with everything multithreaded: the simpler the better. It's hard enough to reason about the simple case. and this is about the ocaml master lock. But it's the only instance I find of somebody discussing recursive mutexes in ocaml.