Threads library

Threads library

[Ernesto Posse]

  Hi. I have a problem with the threads library. Basically I am unable to
access the library.

  The libraries are installed in the default location
(/usr/local/lib/ocaml) (I installed version 3.08.1, on linux
2.6.4-54.5-smp on i686, running SuSE)

  I have the problem when I run the normal toplevel and a customized
toplevel.

  On the normal toplevel, I first try to do

  #load "/usr/local/lib/ocaml/threads/threads.cma";;

which complains about Unix being undefined, so I do

  #load "/usr/local/lib/ocaml/unix.cma";;

but then if I try

  Thread.create;;

it tells me it the value is unbound.

  If I try

open Thread

it tells me "Unbound module Thread".

  If I try the VM threads by doing:

#load "/usr/local/lib/ocaml/vmthreads/threads.cma";;

it complains about a conflict of interface with the normal Threads, and
then it ends the toplevel with

# Fatal error: exception Sys_blocked_io

  I get the same error even if I load the VM threads without loading the
other Thread module.

  I get exactly the same results if I make a customized toplevel as in:

ocamlmktop -thread -custom -o threadtop unix.cma threads.cma -cclib -lunix
-cclib -lthreads



  What am I doing wrong?


  Thanks



-- 
Ernesto Posse
Modelling, Simulation and Design Lab - School of Computer Science
McGill University - Montreal, Quebec, Canada
url: http://moncs.cs.mcgill.ca/people/eposse

Re: [Caml-list] Threads library

[John Prevost]

On Mon, 22 Nov 2004 16:20:31 -0500 (EST), Ernesto Posse
<eposse@cs.mcgill.ca> wrote:
>   Hi. I have a problem with the threads library. Basically I am unable to
> access the library.
> 
>   The libraries are installed in the default location
> (/usr/local/lib/ocaml) (I installed version 3.08.1, on linux
> 2.6.4-54.5-smp on i686, running SuSE)
  {...}

There are two things that will help you here.  The first is that you
want to run your toplevel like this:

ocaml -I +threads

in order to make sure that the threading libraries (and more
importantly, the thread interfaces!) are on the ocaml include path. 
This is *the* most important point, since when you try to refer to the
Threads module, the toplevel is going to look in its path to find the
.mli files, regardless of what has been linked in.

The second thing is that the order in which you #load is relevant.  If you do:

#load "threads.cma";;
#load "unix.cma";;

threads isn't actually loaded--it failed to load.  I suspect you
figured that part out, however.

So, if you just do the -I +threads and then #load "threads.cma"
instead of #load ".../lib/ocaml/threads.cma", you'll succeed for the
normal toplevel.  And with the custom toplevel, you'll still need to
include -I +threads.  You can also use:

#directory "+threads";;

to add to the include path of a running ocaml process.

And as a final note, if you have installed findlib, you can either
make a toplevel with topfind compiled in, or:

#use "topfind";;

in order to get the findlib toplevel extensions.  This will let you do:

#thread;;

to enable threading.  (It adds +threads to the include path, then
loads unix and threads.)

Hope this helps!

John.

Re: [Caml-list] Threads library

[Ernesto Posse]

  Thanks John. It worked.

  I do have another question, and it is about the behaviour of Thread.join.

  I have the following definitions:

open Thread;;

let rec f = function 0 -> () | n -> print_int n; f(n-1);;

let pp (x, y) = (create f x, create f y);;

let ppp = create pp;;

let jpp x y = join(ppp (x,y));

  I would expect that invoking

jpp 8 9;;

  would force the prompt to appear after all threads from ppp(x,y) have
ended, but this doesn't appear to be the case. If I understand
correctly, the join affects only the thread created by ppp, but not
those spawned from it. Is there a simple way to join the rest of the
threads created?



> On Mon, 22 Nov 2004 16:20:31 -0500 (EST), Ernesto Posse
> <eposse@cs.mcgill.ca> wrote:
>>   Hi. I have a problem with the threads library. Basically I am unable
>> to
>> access the library.
>>
>>   The libraries are installed in the default location
>> (/usr/local/lib/ocaml) (I installed version 3.08.1, on linux
>> 2.6.4-54.5-smp on i686, running SuSE)
>   {...}
>
> There are two things that will help you here.  The first is that you
> want to run your toplevel like this:
>
> ocaml -I +threads
>
> in order to make sure that the threading libraries (and more
> importantly, the thread interfaces!) are on the ocaml include path.
> This is *the* most important point, since when you try to refer to the
> Threads module, the toplevel is going to look in its path to find the
> .mli files, regardless of what has been linked in.
>
> The second thing is that the order in which you #load is relevant.  If you
> do:
>
> #load "threads.cma";;
> #load "unix.cma";;
>
> threads isn't actually loaded--it failed to load.  I suspect you
> figured that part out, however.
>
> So, if you just do the -I +threads and then #load "threads.cma"
> instead of #load ".../lib/ocaml/threads.cma", you'll succeed for the
> normal toplevel.  And with the custom toplevel, you'll still need to
> include -I +threads.  You can also use:
>
> #directory "+threads";;
>
> to add to the include path of a running ocaml process.
>
> And as a final note, if you have installed findlib, you can either
> make a toplevel with topfind compiled in, or:
>
> #use "topfind";;
>
> in order to get the findlib toplevel extensions.  This will let you do:
>
> #thread;;
>
> to enable threading.  (It adds +threads to the include path, then
> loads unix and threads.)
>
> Hope this helps!
>
> John.
>
>


-- 
Ernesto Posse
Modelling, Simulation and Design Lab - School of Computer Science
McGill University - Montreal, Quebec, Canada
url: http://moncs.cs.mcgill.ca/people/eposse

Re: [Caml-list] Threads library

[John Prevost]

On Tue, 23 Nov 2004 11:32:50 -0500 (EST), Ernesto Posse
<eposse@cs.mcgill.ca> wrote:
> If I understand
> correctly, the join affects only the thread created by ppp, but not
> those spawned from it. Is there a simple way to join the rest of the
> threads created?

The behavior of Thread.join is specifically to wait for that specific
thread to finish running.  Since your thread ppp simply creates two
other threads and then stops, joining with it waits until those two
threads have been created.  If you want to wait for all of the created
threads to complete, you'll need to do one of a handful of things:

1) The easiest solution is to have your function pp wait until all of
the threads it creates are complete before it exits.  For example:

let pp (x, y) =
  let a = create f x in
  let b = create f y in
  begin
    join a;
    join b
  end

This isn't very extensible, but it's simple, and it works.  The main
lack of flexibility is that the function pp always waits for its
threads to complete, and sometimes you might just want to wait for all
of its subthreads to be created instead.

2) Another solution, which is mostly the same, is to have pp return
the threads it created, and let ppp decide what to do with them.  It's
probably better to change pp to return a list so that this is
extensible to more than two threads:

let pp (x, y) = [create f x; create f y]

let ppp (x, y) =
  create (fun () ->
    let subthreads = pp (x, y) in
    List.iter join subthreads)

This has the advantage that the calling function (ppp) gets to decide
whether to join with the subthreads or with the thread that creates
the subthreads.  It's still on the messy side--particularly because
everybody needs to know what threads go together.

3) You can create a pretty simple module that provides a way to group
threads together, by using the above List.iter technique.  This would
be more complicated, because a general solution needs to deal with
synchronization if multiple threads are creating threads in the
threadgroup, etc.  (I'm actually somewhat surprised that there's not
such a module already in the standard library.)  This would have the
advantage that everything could work the same way, and you can always
choose whether to join to an individual thread or to an entire
threadgroup.  I could whip something like this up later today,
although my first implementation was *too* naive, so I'm not including
it here.  :)

John.

Re: Threads Library

[Juergen Pfitzenmaier]

Xavier Leroy wrote:
> This is correct.  Currently, there is no automatic reclaimation of
> threads whose identifier (the associated Thread.t value) is
> unreachable, because those threads could be "daemon" threads that do
> useful work in the background.

Why not use a special instance of Thread for daemon threads and reclaim
only all normal uses of Thread that became unreachable ?

pfitzen

Re: Threads Library

[Xavier Leroy]

> However, unlike CML, (on Windows/NT at least) the GC does not discard
> threads hung up on channels that are no longer in use by active threads.
> Hence the use of speculative spawning is not safe in WinNT/OCAML. (Early
> experiments generated thousands of threads before I had to kill off the
> program).

This is correct.  Currently, there is no automatic reclaimation of
threads whose identifier (the associated Thread.t value) is
unreachable, because those threads could be "daemon" threads that do
useful work in the background.

> Secondly, it would appear that the semantics of "with_abort" require that
> the wrapper function be called ahead of all "with" functions. But
> experiments where a with-function raises an exception bypass the actions of
> pending "with_abort" functions on non-selected channels. So evidently, one
> should not permit the use of uncaught exceptions inside of "with" functions.
> 
> Finally, where Reppy's CML uses continuations to effect tail calls, I wonder
> about the use of indefinite recursion triggered by a with-function. It would
> seem that one should treat composite event lists in much the same manner as
> "try-with" when it comes to recursion inside a try (resp. with) clause.
> Instead of tail calling from the "with" clause one should return a value to
> the outer level of the "sync" or "select", and then "match" on that value
> before recursing.

I haven't read Reppy's book yet, so I'm not absolutely sure I follow
you here, but generally speaking it is true that the "with_abort"
mechanism is more heavyweight in OCaml than in CML, because it is
implemented with "real" threads in OCaml while CML uses a much more
lightweight callcc-based implementation.

- Xavier Leroy

Threads Library

[David McClain]

I just received a copy of Reppy's new book on "Concurrent ML". I was
delighted to find that the OCAML Threads library incorporates much of his
work with channels and events.

However, unlike CML, (on Windows/NT at least) the GC does not discard
threads hung up on channels that are no longer in use by active threads.
Hence the use of speculative spawning is not safe in WinNT/OCAML. (Early
experiments generated thousands of threads before I had to kill off the
program).

Secondly, it would appear that the semantics of "with_abort" require that
the wrapper function be called ahead of all "with" functions. But
experiments where a with-function raises an exception bypass the actions of
pending "with_abort" functions on non-selected channels. So evidently, one
should not permit the use of uncaught exceptions inside of "with" functions.

Finally, where Reppy's CML uses continuations to effect tail calls, I wonder
about the use of indefinite recursion triggered by a with-function. It would
seem that one should treat composite event lists in much the same manner as
"try-with" when it comes to recursion inside a try (resp. with) clause.
Instead of tail calling from the "with" clause one should return a value to
the outer level of the "sync" or "select", and then "match" on that value
before recursing.

I have implemented a module that provides thread safety, as long as the
above protocols are followed. In effect all events generated by Event.send
and Event.receive are first wrapped in a "with_abort" where the function
spawns a thread to respond to the eventual conjugate operation on the
channel. There are unsafe versions that simply repeat Event.send and
Event.receive for use when it is known that the corresponding thread will
not be ignored forever.

Do I understand the OCAML situation properly?

TIA

David McClain,
Sr. Scientist
Raytheon Systems Co.
Tucson, AZ