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 SAA19966; Fri, 21 Feb 2003 18:58:01 +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 SAA19931 for ; Fri, 21 Feb 2003 18:58:00 +0100 (MET) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h1LHvxH01931 for ; Fri, 21 Feb 2003 18:57:59 +0100 (MET) Received: from fichte.ai.univie.ac.at (markus@localhost [127.0.0.1]) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian -4) with ESMTP id h1LHvpFx015957; Fri, 21 Feb 2003 18:57:51 +0100 Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian -4) id h1LHvneo015956; Fri, 21 Feb 2003 18:57:49 +0100 Date: Fri, 21 Feb 2003 18:57:49 +0100 From: Markus Mottl To: Jacques Garrigue Cc: shiv@ece.ucsb.edu, caml-list@inria.fr Subject: Re: [Caml-list] native threads not parallel? Message-ID: <20030221175749.GE11140@fichte.ai.univie.ac.at> Mail-Followup-To: Jacques Garrigue , shiv@ece.ucsb.edu, caml-list@inria.fr 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> <20030222001142G.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030222001142G.garrigue@kurims.kyoto-u.ac.jp> User-Agent: Mutt/1.4i Organization: Austrian Research Institute for Artificial Intelligence Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 22 Feb 2003, Jacques Garrigue wrote: > 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. Thanks, this seems to be a good explanation for the strange behaviour of native threads under Solaris. Maybe another solution would be to set different scheduler flags, but I haven't read up on this, since our Solaris machines are going to be replaced by Linux ones at our place. Regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- 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