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 9955E820A1 for ; Mon, 19 Aug 2013 16:18:44 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=74.125.82.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of markus.mottl@gmail.com designates 74.125.82.45 as permitted sender) identity=mailfrom; client-ip=74.125.82.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@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-wg0-f45.google.com) identity=helo; client-ip=74.125.82.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wg0-f45.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMCAH4oElJKfVItk2dsb2JhbABagzxRvzCBGAgWDgEBAQEHCwsJFAQkgiQBAQVAARQHHQEDDAYFCwMKLiEBAREBBQEcBhOHfQEDD5kMjFCDAoQAChknDWSHdAEFDI1YgnwHhBIDlXuBaYwtg0MWKYReIA X-IPAS-Result: AlMCAH4oElJKfVItk2dsb2JhbABagzxRvzCBGAgWDgEBAQEHCwsJFAQkgiQBAQVAARQHHQEDDAYFCwMKLiEBAREBBQEcBhOHfQEDD5kMjFCDAoQAChknDWSHdAEFDI1YgnwHhBIDlXuBaYwtg0MWKYReIA X-IronPort-AV: E=Sophos;i="4.89,913,1367964000"; d="scan'208";a="29752833" Received: from mail-wg0-f45.google.com ([74.125.82.45]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Aug 2013 16:18:43 +0200 Received: by mail-wg0-f45.google.com with SMTP id x12so3561147wgg.0 for ; Mon, 19 Aug 2013 07:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tXe4IfJ/kTaELKBqBiVJVASrI/YFtk2vRs23vssWh0M=; b=tvtPrI33SsMJ3KUmbSAcjwl8BYu/dvbB85+SAxfsdcXWti1nQ5g6dhYrVwPCBpEwc2 NVzxBC/RRd2mQ+bfeoxHIqce4XHH8+B+7J2aQrJRTVKhEEfuXK8bIjAfLvop0f8Yh48m EcdIzurccLgiplCldcE1WCchx2aOt4MEmxPODR3T4Pt64zVFwwxhvVTL7lmRCq0c12yO R+HKfLRRDgbX6HJe96FzZL1WkxPsJ/8Iq8DchvBC66viqyOdBB1Gi8aonWLKQz+YHJjJ FY5agwhyiPeoGwEWFrVj1gKiZtsMwGWZV+1AJQRhJVUJLuAE7E3GHFm1Az37UKAnToXL KiPA== MIME-Version: 1.0 X-Received: by 10.180.90.106 with SMTP id bv10mr8078228wib.65.1376921924204; Mon, 19 Aug 2013 07:18:44 -0700 (PDT) Received: by 10.194.172.4 with HTTP; Mon, 19 Aug 2013 07:18:44 -0700 (PDT) In-Reply-To: References: <520DE6F8.9000105@etorok.net> Date: Mon, 19 Aug 2013 10:18:44 -0400 Message-ID: From: Markus Mottl To: Mark Shinwell Cc: Yaron Minsky , =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= , "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Threads and "transaction isolation" in OCaml On Mon, Aug 19, 2013 at 2:10 AM, Mark Shinwell wrote: > I have wondered in the past if we should introduce a syntactic > construct to delimit areas of code that rely on the no-thread-switch > property. I think it would probably be reasonable to actually > check that the expression inside the construct was guaranteed under > the current runtime not to cause a context switch (such expressions are > likely to be, and should be, straightforward). At runtime, the > construct would have no semantic effect. For the scenario described > with bytecode, the construct could just cause a compiler error, at > least at present. This might just require adding two new primitives (enter/leave_transaction) to the standard library. If e.g. the native code compiler sees that there is no allocation in-between, these could even become no-ops. Otherwise the runtime system might just need to check one extra flag when deciding whether to do a context switch, which would have negligible cost and apparently low complexity. Of course, using these primitives requires great care so maybe they should be prefixed with "unsafe_". Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com