From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 5CCDFBB83 for ; Fri, 12 May 2006 19:43:09 +0200 (CEST) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4CHh8HI007095 for ; Fri, 12 May 2006 19:43:08 +0200 Received: from [192.168.1.11] (rescomp-04-35677.Stanford.EDU [128.12.177.67]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k4CHh3IU012536 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 12 May 2006 10:43:03 -0700 In-Reply-To: <1147432929.19900.18.camel@localhost.localdomain> References: <1147432929.19900.18.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25A4782F-1F23-4B18-8FB2-1627C3BF1C3D@cs.stanford.edu> Cc: francois@rouaix.org, caml-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Ted Kremenek Subject: Re: [Caml-list] Co-existing with non OCaml threads Date: Fri, 12 May 2006 10:43:02 -0700 To: Gerd Stolpmann X-Mailer: Apple Mail (2.749.3) X-Miltered: at nez-perce with ID 4464C92C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 threads:01 run-time:01 threads:01 ocaml:01 run-time:01 thread-safe:01 gerd:01 stolpmann:01 o'caml:01 thread-safe:01 o'caml:01 heap:01 wrote:01 caml-list:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.0.3 This is very interesting. Thank you for pointing this out. I have some questions that would clarify a few things for me. Because of the run-time lock, should I gather that the threads are still essentially cooperative threads? For example, does it work this way: if a thread holding the master lock is switched out and the kernel schedules another thread, that other thread will start running and try and acquire the lock. It won't be able to, so it goes back to sleep, and another thread will wake up, try and acquire the lock, goes back to sleep, and so on, until the original thread holding the lock is rescheduled. Only when the thread releases the lock (yields?) will another thread be able to run. Is this how it works? If so, this would lend itself to extremely poor performance: if I had 100 threads, 99 of them may have to wake up and go to sleep before the original one is scheduled. That is 99 useless context switches. Or rather is the lock acquired and released (within the generated native code for the OCaml part of a program, not C code) on calls to the memory management functions and other run-time code that are not thread-safe? This is also seems slow, since the heap is actively manipulated all the time, so locks will constantly be acquired and released, and you will have the same wake-up, make little or no progress and go back to sleep problem I mentioned before. Your last email said that only one thread is allowed to run OCaml code at any time, so it seems to me that this mutual exclusion must come from somewhere. I'm very curious to know how this is implemented. I gather that most people want to use threads in OCaml to have multiple threads running OCaml code, and not necessarily have a bunch of threads executing called C code (allowing the master lock to be released). I'm just trying to understand how actual performance would ever resemble anything desirable. Just curious. Thanks for the informative email. Ted On May 12, 2006, at 4:22 AM, Gerd Stolpmann wrote: > If you compile ocaml with pthread support, the O'Caml threads are real > Linux threads. When using them, be aware of: > > - The memory management code is not thread-safe. That means > only one thread is allowed to run O'Caml code at any time. > To ensure this there is the so-called "master lock". You > can acquire the master lock by calling > > leave_blocking_section() > > and you can release it by > > enter_blocking_section()