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 5E6EE820A1 for ; Fri, 16 Aug 2013 18:07:25 +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.173; 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.173 as permitted sender) identity=mailfrom; client-ip=74.125.82.173; 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-we0-f173.google.com) identity=helo; client-ip=74.125.82.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-we0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYCAA1NDlJKfVKtjWdsb2JhbABbgztRvx+BIwgWDgEBAQEHCwsJEgYkgiQBAQQBDDQBFAcdAQMBCwYFCw0uIQEBEQEFARwGEwiHdQEDCQacbIxQgwKEJgoZJw1kh3QBBQyNSYJIMweEEgOVe4FpjC2DQxYphF4ggSwk X-IPAS-Result: AoYCAA1NDlJKfVKtjWdsb2JhbABbgztRvx+BIwgWDgEBAQEHCwsJEgYkgiQBAQQBDDQBFAcdAQMBCwYFCw0uIQEBEQEFARwGEwiHdQEDCQacbIxQgwKEJgoZJw1kh3QBBQyNSYJIMweEEgOVe4FpjC2DQxYphF4ggSwk X-IronPort-AV: E=Sophos;i="4.89,895,1367964000"; d="scan'208";a="29519076" Received: from mail-we0-f173.google.com ([74.125.82.173]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Aug 2013 18:07:24 +0200 Received: by mail-we0-f173.google.com with SMTP id x54so624837wes.18 for ; Fri, 16 Aug 2013 09:07:24 -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:content-transfer-encoding; bh=gsH4pMthGGxgFUObLj320CNfXvUgTZ/dmFObSEWRToA=; b=aTtv0NVqNSbrgMNmexccyJw3fqGK9fEk0cKNdKuOYKCBoiDdSRGhjn4r5mE1lLdSWo xw3bP+NNJerIgampTG5kZTQ4joUBkJKZ3JTFDzC3Sl0wbslBeCpBt1Ke6xJHHtPTn0rW XsKVMoQe/p8a0qdWT1DSupBvxVzU/3bKJ3rn4PPphyDEwN2/cln3XtJSBzlxmNUYQ0ih JUUTNO1uahgWzWJ5PLgq1LDRODtm7sFtYVuIFo2K7J9nHLrOuNNZA1Vy0pINwtIKjunC tJCHsHZ4yK8EHAjMVDztoJ57cJCupvQGjlAN4QxELd3yDt19omcRpk0PO9AX/e4pUBW1 28ig== MIME-Version: 1.0 X-Received: by 10.180.92.98 with SMTP id cl2mr1583696wib.15.1376669244415; Fri, 16 Aug 2013 09:07:24 -0700 (PDT) Received: by 10.194.172.4 with HTTP; Fri, 16 Aug 2013 09:07:24 -0700 (PDT) In-Reply-To: <520DE6F8.9000105@etorok.net> References: <520DE6F8.9000105@etorok.net> Date: Fri, 16 Aug 2013 12:07:24 -0400 Message-ID: From: Markus Mottl To: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Threads and "transaction isolation" in OCaml On Fri, Aug 16, 2013 at 4:46 AM, T=F6r=F6k Edwin wrote: > I wrote a little test program and this is not true for bytecode -vmthread= , but seems to work for bytecode -thread and native -thread: Thanks for this example. It's not surprising that this trick does not work with VM-threads, but I have never seen anybody use them for anything so I'm not bothered by this. But, surprisingly to me, I did manage to get a failure with byte code + POSIX threads when running this example on Linux (Centos 6.4) via VMware Fusion (Mac OS X). I admittedly have never thoroughly tested these "transactions" with any sort of byte code, since I practically exclusively run native code. Still, I would have expected the runtime to work identically here. Interestingly, I couldn't replicate the error on a VPS running the same OS and compiler, but using Xen (via Linode) instead of VMware Fusion for virtualization. Note that some open source libraries, e.g. the Nano_mutex module in Jane Street Core, depend on this trick so it seems important to figure out how safe and portable it really is. It would be a huge pity to do without, since it can offer quite dramatic performance improvements for certain applications. Does anybody know a reason why byte code + POSIX threads might fail with this trick? > I'd consider this very fragile as you'd need to know the implementation d= etails of every function you call (or only calling your own safe functions)= . I was surprised to find out that even Array.fold_left creates a temporary= ref for example. It would certainly be unwise to call any function whose implementation is not fixed and fully understood wrt. transaction isolation. This trick is obviously low-level and its use should be clearly documented by the developer. Most of the time it will only consist of a few assignments or pattern-matches anyway. Regards, Markus --=20 Markus Mottl http://www.ocaml.info markus.mottl@gmail.com