From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA14131; Fri, 21 Feb 2003 16:11:58 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA14097 for ; Fri, 21 Feb 2003 16:11:57 +0100 (MET) Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h1LFBsT26132 for ; Fri, 21 Feb 2003 16:11:55 +0100 (MET) Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17]) by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id AAA25605; Sat, 22 Feb 2003 00:11:50 +0900 To: shiv@ece.ucsb.edu Cc: caml-list@inria.fr Subject: Re: [Caml-list] native threads not parallel? In-Reply-To: <1045801453.1601.8.camel@cbshost-12-107-11-69.sbcox.net> References: <847A10BA-4528-11D7-8C93-000393942C76@ece.ucsb.edu> <20030221091524C.garrigue@kurims.kyoto-u.ac.jp> <1045801453.1601.8.camel@cbshost-12-107-11-69.sbcox.net> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030222001142G.garrigue@kurims.kyoto-u.ac.jp> Date: Sat, 22 Feb 2003 00:11:42 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: shivkumar chandrasekaran > Sorry, but let me ask again. I *know* that ocaml threads cannot use > multiple processors. That was not the subject of the thread I cited. I > should have been clearer. > > If I am recalling correctly, Xavier has mentioned before that in > *native-code* (see subject) ocaml will allow C code to run in parallel. > Markus' email was precisely on that point as was mine. I have C code > that I would like to execute on a processor different from the ocaml > thread one. Apparently, as I gather from the cited email of Markus > Mottl, this did occur (at least on some dual processor Linux machines) > when the corresponding C code was bracketed with "enter/leaving_blocking > section ()" calls, and, *I assume*, calling the C-code from a separate > ocaml thread using Thread.create. I see, after rereading carefully the original mail, I could understand what this is about. IIRC, the distinction is not between native code and bytecode, but between native threads and caml threads. You can use native threads in bytecode, and it should work also (but I might be wrong). About the problem Markus is describing, and if he is using Thread.create as you suggest, I may see a cause. Seeing that the code for caml_thread_new in posix.c contains no enter_blocking_section, if you create a thread with Thread.create, it will immediately block trying to get the caml mutex. It will get it eventually from the main caml thread through a yield, but a clever scheduler will schedule this thread on the same processor (it starts just when the previous one stops). As Markus says, after a long time the scheduler may realize this choice was wrong and change the processor, but this is scheduler dependent. I may be utterly wrong in my inference, but if this is right, a better solution would be to explicitely start the thread with pthread_start from the C side. Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners