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 SAA08483; Mon, 24 Feb 2003 18:40:11 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA08364 for ; Mon, 24 Feb 2003 18:40:10 +0100 (MET) Received: from xanadu.ece.ucsb.edu (xanadu.ece.ucsb.edu [128.111.56.51]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h1OHe8H16584 for ; Mon, 24 Feb 2003 18:40:09 +0100 (MET) Received: from ece.ucsb.edu (gimli.ece.ucsb.edu [128.111.56.252]) by xanadu.ece.ucsb.edu (8.12.2/8.12.2) with ESMTP id h1OHe7Pr009119 for ; Mon, 24 Feb 2003 09:40:07 -0800 (PST) Date: Mon, 24 Feb 2003 09:39:50 -0800 Subject: Re: [Caml-list] native threads not parallel? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Shivkumar Chandrasekaran To: caml-list@inria.fr Content-Transfer-Encoding: 7bit In-Reply-To: <20030222001142G.garrigue@kurims.kyoto-u.ac.jp> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk This seems to match the observed behavior on my machine. I could infer that the two threads were being executed in parallel; just not on different processors simultaneously. Thank you very much!! On Friday, February 21, 2003, at 07:11 AM, Jacques Garrigue wrote: > 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 > --shiv-- ------------------- 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