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 89A04820A1 for ; Fri, 16 Aug 2013 04:55:40 +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.182; 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.182 as permitted sender) identity=mailfrom; client-ip=74.125.82.182; 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-f182.google.com) identity=helo; client-ip=74.125.82.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-we0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8CAE6UDVJKfVK2jWdsb2JhbABbDoMtUKxqkiuBHggWDgEBAQEHCwsJEgYkgiQBAQVAARQHEgsBAwwGBQsNDSEhAQERAQUBChIGExKHawEDDwycZIxRgwKEJQoZJwMKZId0AQUMjUmCeweEEgOVe4FpgS2KfoNCFimEA1og X-IPAS-Result: Al8CAE6UDVJKfVK2jWdsb2JhbABbDoMtUKxqkiuBHggWDgEBAQEHCwsJEgYkgiQBAQVAARQHEgsBAwwGBQsNDSEhAQERAQUBChIGExKHawEDDwycZIxRgwKEJQoZJwMKZId0AQUMjUmCeweEEgOVe4FpgS2KfoNCFimEA1og X-IronPort-AV: E=Sophos;i="4.89,891,1367964000"; d="scan'208";a="29472756" Received: from mail-we0-f182.google.com ([74.125.82.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Aug 2013 04:55:39 +0200 Received: by mail-we0-f182.google.com with SMTP id q59so895464wes.41 for ; Thu, 15 Aug 2013 19:55:39 -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=3Zi9+jSXm5naV8QFeepr6I3m0gpa01ytacWBMj5BQz0=; b=lFk1dNn1NXwzB3+LM5rqbF6R8U7AlQHRM9foyDuFWx3I6lRvSN3s3vl52uJKLkEFCc 9cPxcByx6YG58+FfecmzBfSVdW73uI1ABsSpiGXh7YXPKXRjK/A0e/hPr1ehonoYgltI V3TD/r4c3uQcwW4ioYfYYikFLKXjx8Clnq2ksHP7RNBSp4AIxs8gctWxCz5wUz8FrxB4 7/EkNCMwNMGDw45HwijoNrf2ZedybKSliXy3GhPyT7QkbjOTAIbN6Lw26e/l3I553J/i 0gvmFSYlyQVQ/FbZQ3ub78UbRupskEKIaRW5TLQTZUoFzZ/5TIkfZZBmS1mVGrTiuP3m T68w== MIME-Version: 1.0 X-Received: by 10.194.235.138 with SMTP id um10mr12268413wjc.30.1376621739618; Thu, 15 Aug 2013 19:55:39 -0700 (PDT) Received: by 10.194.172.169 with HTTP; Thu, 15 Aug 2013 19:55:39 -0700 (PDT) In-Reply-To: <20130815212826.7sz760lhs0c00k84@webmail.mit.edu> References: <20130815212826.7sz760lhs0c00k84@webmail.mit.edu> Date: Thu, 15 Aug 2013 22:55:39 -0400 Message-ID: From: Markus Mottl To: John F Carr Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Threads and "transaction isolation" in OCaml That's a good point. I had never seen a problem with this, but wasn't sure whether this is just due to my particular use cases in the past (may have involved atomic values only) so I've verified this in the source now to be sure. The "caml_ref_table", which contains all fields on the major heap that refer to the minor heap, will be reallocated if it runs out of space, but I don't see any place where this would actually run the GC. The same seems to be true of the "gray_vals" table that may also get involved. I guess such reallocations are exceedingly rare in practice, because the GC will usually run before the tables get full and clear them out. I'm sure the OCaml team will let us know if I missed anything, but I think assignments are safe in all circumstances (including your example), no matter what the source or destination values are. On Thu, Aug 15, 2013 at 9:28 PM, John F Carr wrote: > Do you mean allocation or garbage collection? > > Generational garbage collectors can collect without allocation when you > assign a > young object to a field of an older object. There is (or may be) a list of > intergenerational (older to younger) references. When that list exceeds a > threshold, the GC may do a minor collection. > > I have not checked what the current implementation of OCaml does in this > case. > > let x = ref (ref 0) in > let y = ref 1 in (* allocation triggers GC; x is old and y is young *) > ... work here ... > x := y (* may cause GC *) > > >> Hi, >> >> I just wondered how much we can rely on current OCaml-semantics where >> context-switches are impossible as long as there are no allocations. >> >> E.g. pattern-matches, array and record field assignments, etc., can be >> safely chained together in one "transaction" without having to fear >> that another thread will interrupt them. This is extremely useful for >> optimizing certain applications where lock acquisitions might just be >> too expensive. >> >> There already are some corner cases where things may be >> platform-dependent, e.g. calling functions tail-recursively that take >> more arguments than there are available CPU-registers. In that case >> the compiler may pass arguments by allocating blocks on the heap. But >> I think people that care about such obviously brittle semantics know >> where to be careful. >> >> Anyway, is it considered reasonably future-safe to write code of that >> sort? I'd rather not have new compiler optimizations, etc., interfere >> with these assumptions in the near future. >> >> Regards, >> Markus >> >> -- >> Markus Mottl http://www.ocaml.info markus.mottl@gmail.com >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com