Re: [Caml-list] Native threads under Debian 3.0r0

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Berke Durak <berke@altern.org>
> 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