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 BAA29887; Thu, 5 Sep 2002 01:39:28 +0200 (MET DST) 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 BAA30032 for ; Thu, 5 Sep 2002 01:39:27 +0200 (MET DST) 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 g84NdM102699 for ; Thu, 5 Sep 2002 01:39:23 +0200 (MET DST) 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 IAA17420; Thu, 5 Sep 2002 08:39:10 +0900 To: berke@altern.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] Native threads under Debian 3.0r0 In-Reply-To: <20020904151422.GA336@gogol> References: <20020904191523M.garrigue@kurims.kyoto-u.ac.jp> <20020904130151.GB1375@kiefer.ai.univie.ac.at> <20020904151422.GA336@gogol> 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: <20020905083852F.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 05 Sep 2002 08:38:52 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Berke Durak > On Wed, Sep 04, 2002 at 03:01:51PM +0200, Markus Mottl wrote: > > On Wed, 04 Sep 2002, Jacques Garrigue wrote: > > > > > So the answer is: a native code thread should be allocating some data, > > > otherwise it cannot be interrupted. The problem does not exist for > > > bytecode. > > > > The main consideration is obviously native code performance. OTOH, some > > people might want to guarantee that their threads never get stuck. I > > don't know what solution would be useful for them. Maybe some runtime > > or command-line switch that trades efficiency against such scheduling > > problems. Not impossible to do, but this is a design question. I expect you would just have to insert explicit checks for pending signals like in bytecode: at function calls and in loops. Of course it is always possible to call Thread.yield by hand, but I'm a bit afraid of the extra overhead since this is a system call. And it may mean your process is executed for shorter periods. Note that there is only a real problem for long running loops doing purely numerical computation without any allocation. And inserting an allocating function call somewhere in an outer loop should solve the problem: ignore ([1] @ [2]) for instance. > Sorry about my ignorance, but aren't threads scheduled by the kernel > when using libpthread ? (That would make sense, since I get extra > processes when I create extra threads). I mean, aren't the threads > automatically preempted ? > > If not, couldn't it be possible to preempt them automatically using > the interval timer ? This is exactly what is done. However such a preempted thread will not release its caml mutex, which makes sure allocation doesn't occur in two threads simultaneoulsy for instance. So C threads will run, but not other caml threads, since they would have to get the mutex. As I tried to explain in my previous mail, the interval timer lets the current thread know that it should free the mutex as soon as possible, but this is the responsibility of the running thread to do so. 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