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 900857EF38 for ; Thu, 16 Jul 2015 11:43:00 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of goswin-v-b@web.de designates 212.227.15.14 as permitted sender) identity=mailfrom; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; 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@mout.web.de) identity=helo; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAQA6fKdVnA4P49RaxEKDRAKBQkwBAQEBAQESAQEBAQEGDQkJIS6EJAEBBDoyChMLGAklDwUoiEwBGck+H4V4AQsgikqBAoQZdIMXgRQFlA44jBeIPAyQOIQkgXEJFwSBIwEBAQ X-IPAS-Result: A0BFAQA6fKdVnA4P49RaxEKDRAKBQkwBAQEBAQESAQEBAQEGDQkJIS6EJAEBBDoyChMLGAklDwUoiEwBGck+H4V4AQsgikqBAoQZdIMXgRQFlA44jBeIPAyQOIQkgXEJFwSBIwEBAQ X-IronPort-AV: E=Sophos;i="5.15,487,1432591200"; d="scan'208";a="170436191" Received: from mout.web.de ([212.227.15.14]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jul 2015 11:42:55 +0200 Received: from frosties.localnet ([95.208.221.151]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MUzq1-1ZTZ0l07p7-00YV5K for ; Thu, 16 Jul 2015 11:42:54 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.84) (envelope-from ) id 1ZFfgr-0000DB-7H for caml-list@inria.fr; Thu, 16 Jul 2015 11:42:53 +0200 Date: Thu, 16 Jul 2015 11:42:53 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20150716094252.GA32592@frosties> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:D34QwADVqDqi/PmwJEab3UdZ5uUQoa7BhXvuF9LgfePZpbZHB6n VfYjoWg5NaEkgFyZAp77q2A6NxjE9up/cWNN2/JKzpixw6z9bxojLW3Izh2o2Hvbj0atPzh rlQClPS/wkn91/rcBt3yAqSKpv2ZeNvX9ZY+oK3uMsrXnGFVASI459YeBwflBJvLrHj0R3O oESTDqSR+85PIiTEz0NGg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rYFmvKaSlW8=:6YhXKzyCTSUI/8WSBUWcTz c0Q9y/vXGTDp4H1PxMMQphgElhztDtOQG6By/l/SDF3gp2wUosT0X67g7V+mVAkmhjrrk+Jxz ewcFu+QEbmhIpMiAlahMMY1C7wMTDYXt6gR0J2k3Hwm9nCpGKR8qbDW5OmknfT164kLcuB9lj x4Q+jOWGPt96bLqzATWarqGt8Gzi1E9jCNT6iZdkc/8Bzjyw0xJ7KD9FMB9XXeupSFLq4sso6 8ofMXV8Ilb9tjTa6kl2FuUvOA845CoSM/uTLgkUQeEd8ETFhL2RBpSaJ5+rPi9TSVZ/Qtr1ol HFj4eXpos/2X5gEppq1NHpN+N+Yk076r1ZazNQAreD7FemEmPHz1pBj3QTPi4Wy8JYo4y35DR Xb6Ct1rhGfUXel/tBxfeFB4sqlNbcKP79o1rmXpnFLvw7OEG0/EdJOwge9pPOQXp7zIF7gkje dWTFSTkMKUMH304+S8RzG6yeA+kPZVBeEPO5laAzj6SQezflU2eE8wIPbj5B4IDeb+rHwML+/ 2OAtQGEPy5FCA5QPE3cNg9aUowZaeSFxB1ms1SBfCtJlDmTnSF4QVnO7lOGjRuV6r1GWeX6b+ gkQJoQSrjlwd1GxAm1HL3SYwHM9PU0GvifKlDs5IZfp5ikqYq3xkyFmZID7CEeGegeZ+DGUhU DPXVCjyJMBdVhGATa+3qNw+36DFD2TJSp5iEBVh5hpwoEPw== Subject: Re: [Caml-list] Parallelism in newer versions of ocaml On Thu, Jun 18, 2015 at 03:53:46PM -0400, Kenneth Adam Miller wrote: > Its my personal gathering that the development of ocaml has always been > driven with the conviction that things should be done with a mathematical > foundation that supports doing things well over just getting them done > sooner. Quality over quantity kind of thing. > > I was wondering what kinds of typing rules or new language constructs or > otherwise judicious restrictions might be put in place for the facilitation > of doing concurrency very well in ocaml, or if there are even any. Possibly > it is just the code that the compiler produces that just now will actually > resolve a thread creation function call? My thinking is the GC wasn't > written with concurrent accesses in mind, but at the same time, the pi > calculus would seem close to home with respect to the ocaml philosophy. > > Can any body comment on any of this? I think it comes down to 2 major things: 1) race conditions accessing data structures Luckily anything immutable is mostly save from this so ocaml is in a better position there than other languages. Ocaml would have to insert memory barriers before modifying any mutable or passing objects to other threads. Still there are a number of data structures in the standard library that would need to have thread safe versions or the user has to wrap them with locks (error prone). 2) Garbage collection in a shared world With all threads having access to globals or when sharing objects between threads it becomes much harder to determine what is alive in a way that doesn't cost more cpu time than you gain from having multiple cores. I believe that for it to work well something like the generational heaps needs to be implemented / infered for thread. Temporary data should reside on a thread/core local heap and be handled by the local GC alone. Data that gets shared between threads then needs to go to a shared heap, either by being allocated there from the start (hard for the compiler to do) or getting moved there (costs time to check for it and to move as needed). It also depends majorly on what kind of multithreading/multiprocessing you use. In recent years I have switched over more and more to a event / message passing approach to multiprocessing. Don't have shared data at all (if you can avoid it). Instead have the data flow from one thread to another where you always pass ownership to the new thread. Confused? Imagine you want to build a car from lots of parts with lots of workers. Traditionall multithreading would have one workplace where the car is to be build. Each worker aquires the key to the workspace, locks himself in and adds a wheel or door or whatever. Then he returns the key for the next worker. As you can imagine there will be a lot of waiting for the key. And the key might get lost. There are lots of pitfals in a lock based approach. Now think about how a modern car factory works. Instead of moving around the workers and guarding the car with a key you move the car from station to station. Each station has implicitly sole ownership of the car and adds a tire or door or whatever and then passes the car on to the next station. There is no key (no locking), the key can't get lost. And it's less likely that you loose a whole car. The extra benefit of the event/message passing approach is that you can easily go from multithreading to multiprocessing to distributed system. And hey, multiprocessing would work great for ocaml with each process running its own ocaml and own GC all the cores of a cpu can be used. You just need a problem where the communication between processes isn't the deciding factor. :( MfG Goswin